I'd recommend gradual changes. Let's just move the log line and fix the ec 
creation for now. 

Chuck Hill
Gevity Consulting Inc.

Sent from my mobile device. 

> On Jan 27, 2015, at 4:33 PM, OC <[email protected]> wrote:
> 
> Chuck,
> 
>> On 28. 1. 2015, at 1:23, Chuck Hill <[email protected]> wrote:
>> 
>> This could just be a thread priority thing.  When the first thread does the 
>> unlock, the second locks and proceeds and the println output to the log is 
>> delayed.  Ive definitely see that with NSLog were the order of output from 
>> concurrent threads is sometimes out of sequence in the logs.
> 
> Right you are, as always; probably I should move the log above the unlock.
> 
> Hopefully it was the sole reason.
> 
> Well, now I'm going to create my temporary EC in the locked OSC as you 
> suggested in previous e-mail, and will see what happens...
> 
> (Or do you suggest to change the code completely?)
> 
> Thanks again!
> 
>> On 2015-01-27, 3:04 PM, "OC" wrote:
>> 
>> Hello there,
>> 
>> since I wrote an awk script to check whether my OSCs get unlocked properly, 
>> I've bumped into one very strange thing in the locks.
>> 
>> First, my code is pretty straightforward (assuming we should lock OSC at 
>> all, which is debatable -- based on 
>> http://terminalapp.net/dr-optimistic-locking/; Chuck says well all right, 
>> though it should be sufficient to catch some notifications instead):
>> 
>> ===
>>        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 ...
>>            tempec.saveChanges()
>>            println "... saved successfully!"
>>       } catch (exc) {
>>            ... reporting and logging error -- does not happen ...
>>       } finally {
>>            osc.unlock()
>>            println "$osc UNLOCKED FOR CU $sess.currentUser.login"
>>       }
>> ===
>> 
>> and in one place in my logs, there is
>> 
>> ===
>> 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!
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU CEZProdej
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU EPETas
>> ===
>> 
>> What the darn?!? This should not be possible, or am I completely missing the 
>> point of osc.lock()?!? :-O
>> 
>> In the vicinity, all the other logs looks all right, no exception not other 
>> error reported.
>> 
>> As usual, I'll be pretty grateful for any insight,
>> OC
>> 
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>> 
>> This email sent to [email protected]
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to