Re: ERXObjectStoreCoordinator can be locked twice?!?
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