On Jan 27, 2015, at 4:32 PM, Chuck Hill <ch...@gevityinc.com> wrote:
>
>
> On 2015-01-27, 3:28 PM, "Ramsey Gurley" wrote:
>
>
> On Jan 27, 2015, at 4:19 PM, Chuck Hill <ch...@gevityinc.com> wrote:
>
>> Are you using this?
>>
>> /**
>> * This class implements EOF stack pooling including EOF stack
>> synchronizing.
>> * It provides a special ERXEC.Factory in order to work without any changes
>> in existing
>> * applications. The number of EOObjectStoreCoordinators can be set with the
>> * system Property
>> <code>er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators</code>.
>> * Each Session will become one EOObjectStoreCoordinator and the method
>> * <code>newEditingContext</code> will always return an
>> <code>EOEditingContext</code>
>> * with the same <code>EOObjectStoreCoordinator</code> for the same
>> <code>WOSession</code>.
>> * This first release uses round-robin pooling, future versions might use
>> better algorithms
>> * to decide which <code>EOObjectStoreCoordinator</code> will be used for
>> the next new
>> * <code>WOSession</code>.<br>The code is tested in a heavy multithreaded
>> application
>> * and afawk no deadlock occures, neither in EOF nor directly in Java.
>> *
>> * @author David Teran, Frank Caputo @ cluster9
>> */
>> publicclass ERXObjectStoreCoordinatorPool {
>
> I think so. From a different thread:
>
> another weird case: this application is run single-instance (but
> ERXObjectStoreCoordinatorPool.maxCoordinators=3,
> WOAllowsConcurrentRequestHandling=true).
>
>
> OK, so that handily explains the OSC lock logging below – they are different
> OSC instances. Single instance and three stacks seems odd, like someone
> maybe misunderstood what this was doing?
>
>
>> 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 …
>
> 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/
Interesting, I would have thought locking the ec did lock the OSC.
BTW, OC, are you using binary blobs for your banners in the database? Because
if you are, the ERXOSCPool leaks memory and big snapshots make it leak much
faster.
>
>
> //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.
>
>
>
>> 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 (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>>
>> This email sent to ch...@gevityinc.com
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>>
>> This email sent to rgur...@smarthealth.com
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
