• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ERXObjectStoreCoordinator can be locked twice?!?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ERXObjectStoreCoordinator can be locked twice?!?


  • Subject: Re: ERXObjectStoreCoordinator can be locked twice?!?
  • From: OC <email@hidden>
  • Date: Wed, 28 Jan 2015 01:12:13 +0100

On 28. 1. 2015, at 0:32, Chuck Hill <email@hidden> wrote:

> OK, so that handily explains the OSC lock logging below – they are different OSC instances.

I suppose toStrings logs out the hashCode, and if it does, they are the same instance:

>> ===
>> 26.1 14:06:03: er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR CU CEZProdej
>> ... saved successfully!
>> 26.1 14:06:03: er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR CU EPETas
>> ... saved successfully!


-- "@5d5e3b92" in both cases. There are other cases with "er.extensions.eof.ERXObjectStoreCoordinator@52ab6c19[name=unnamed]", which I assume is another instance of OSC, and which indeed do not clash with "@5d5e3b92" at all. (The third one was never used, it seems.)

>> ===
>>         EOEditingContext ec=auction.editingContext()
>>         EOObjectStore osc=ec.rootObjectStore()
>>         osc.lock()
>>         try {
>>             logln "$osc LOCKED FOR CU $sess.currentUser.login"
>>             EOEditingContext tempec=ERXEC.newEditingContext()
>>             ... creating localInstanceIn as needed, updating them as appropriate …
>
> Wat?
>
> http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588
>
> I don’t understand why this would be necessary, and I’m afraid to ask ;-) Anyway,
>
> You’ve met Miguel, right?  :-)
> http://terminalapp.net/dr-optimistic-locking/

Well that's the source of my code; actually we have discussed it a short time ago

===
On 24. 1. 2015, at 0:30, Chuck Hill <email@hidden> wrote:
>>>>         EOEditingContext ec=auction.editingContext()
>>>>         EOObjectStore osc=ec.rootObjectStore()
>>>>         osc.lock()
>>> Why are you locking this?  Nothing in the code below needs it.
>>>
>> Learnt it here: http://terminalapp.net/dr-optimistic-locking/ -- have I misunderstood something of importance?
>>
> Ah, that Miguel, always worrying!  :-)  OK, I see what you are after.  IIRC, you can also handle this by catching notifications.  That discussion was a long time ago, I forget the particulars and don’t have time to re-read all of it now.
>
> Chuck
>
>>>>        try {
>>>>             EOEditingContext tempec=ERXEC.newEditingContext()
>>>>             tempec.fetchTimestamp=System.currentTimeMillis()
>>>> ... ... ...
===


> //You should be doing this if you want to ensure a peer ec in the same osc
> EOEditingContext tempec = ERXEC.newEditingContext(osc);
> Yes with multiple stacks NOT doing that could lead to unexpected results.

Thanks, that looks like a pretty important point! :)

The source of my code is Miguel all right -- at http://terminalapp.net/dr-optimistic-locking/ he suggests to lock OSC and also he says “Do as I wrote on the previous article” (and also, incidentally, “create multiple EOF stacks”).

The “previous article” is http://terminalapp.net/recovering-from-optimistic-locking-exceptions/, where the code looks like

===
    EOEditingContext context = new EOEditingContext();
===

which I have just replaced by -- in my faulty opinion equivalent -- EOEditingContext tempec=ERXEC.newEditingContext(). I simply did not know I should use any argument there, ane Miguel does not point that out in any of his articles...

That's all. Well I'm going to replace it by “ERXEC.newEditingContext(osc)”, hopefully it will help!

Well perhaps before I do that -- is the Miguel's approach completely wrong? Should I trash the complete code and replace it by something else, with an utterly different approach?

Thanks a big lot,
OC


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >ERXObjectStoreCoordinator can be locked twice?!? (From: OC <email@hidden>)
 >Re: ERXObjectStoreCoordinator can be locked twice?!? (From: Chuck Hill <email@hidden>)
 >Re: ERXObjectStoreCoordinator can be locked twice?!? (From: Ramsey Gurley <email@hidden>)
 >Re: ERXObjectStoreCoordinator can be locked twice?!? (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: ERXObjectStoreCoordinator can be locked twice?!?
  • Next by Date: Re: ERXObjectStoreCoordinator can be locked twice?!?
  • Previous by thread: Re: ERXObjectStoreCoordinator can be locked twice?!?
  • Next by thread: Re: ERXObjectStoreCoordinator can be locked twice?!?
  • Index(es):
    • Date
    • Thread