IIRC ERXEC is locked when you touch any of its methods. Unlocking happens *only* when ERXEC.unlockAllContextsForCurrentThread() is called. You can see where that is called in the source code. On Jul 11, 2012, at 6:56 AM, Matteo Centro wrote:
> From some experimentation it looks like that even in Session.terminate locks > are automagically generated even without explicit lock/unlock. > > Any thoughts? > > > Matteo > > On Tue, Jul 10, 2012 at 9:33 AM, Cheong Hee (Gmail) <[email protected]> wrote: > I think you are right or at least this is the impression I had the last time > on this subject. I plan to move from MultiEC locking manager to ERXEC ec. > As usual, I could be wrong.. > > ----- Original Message ----- > From: Matteo Centro > To: Paul Dunkler > Cc: [email protected] Dev Apple ; Wonder Project > Sent: Monday, July 09, 2012 6:47 PM > Subject: Re: [Wonder-disc] ERXEC and locking > > Actually I noticed that removing all the locks (even the forgotten ones) > seems to have solved the problem... I had 100000 unique users on 22 instances > running for a day and no deadlocks. > > Any thoughts about stuff that is done in the Session.terminate? I need to do > some cleanup if the session terminates, do I get automatic lock unlock in > that scenario or the termination happens in a separate thread and so I have > to manually lock/unlock? > > Thanks, > > > Matteo > > On Mon, Jul 9, 2012 at 12:19 PM, Paul Dunkler <[email protected]> > wrote: >> I recently "Wonderized" a legacy WO application and I have a strange race >> condition that happens very rarely and only under extremely high load. >> Application extends ERXApplication, Session extends ERXSession and so on, I >> removed all "new EOEditingContext()" and replaced them with >> ERXEC.newEditingContext() >> but >> I forgot to remove some ec.lock() and ec.unlock() >> >> I am quite convinced that removing all locks and unlocks will bring me to a >> non deadlocking situation but I still want some reassurements >> I read a lot of stuff and I'm here to ask to you gurus a final word on the >> locking rule I inferred from what I read: >> >> If you always use ERXEC you can safely remove all lock and unlocks except >> for stuff that happen in background threads... >> >> Is it true? > > I think yes, its true. We are actually using Wonder Editing Contexts only and > do not have any other locking stuff. Everything runs fine. > >> >> What about stuff that happens in session.terminate()? I would say that it >> should have explicit lock/unlocks but any opinions are welcome. >> >> Thanks, >> >> >> Matteo >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ >> Wonder-disc mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > > -- > Mit freundlichen Grüßen > > Paul Dunkler > > > > <xyrality_logo_medium.png> > > ----------------------------------------------------- > XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg > Paul Dunkler • Technical Director > Mail: [email protected] > Tel: +49 (0) 40 35 73 001 41 > Mobil: +49 (0) 151 252 228 42 > Fax: +49 (0) 40 35 73 001 99 > Web: http://www.xyrality.com/ > Registergericht: Hamburg HRB 115332 > Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr > ----------------------------------------------------- > > > > > _______________________________________________ > 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/chng34%40gmail.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/kelleherk%40gmail.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]
