Thanks Kieran. I've implemented your solution and will roll it through to prod
within a couple of days. I have deadlocks on at least a daily basis so if
those disappear it will be another validation of your work... not to mention
once again earning my gratitude.
Slán,
Jon
On 2/28/11 8:50 AM, Kieran Kelleher wrote:
Hi Jon,
On Feb 28, 2011, at 10:28 AM, Jon Nolan wrote:
Hi Kieran,
I have a multi-threaded app and I'm starting to run into deadlock issues on EC
locking/unlocking (OSC really). After a weekend of digging and researching I
think your solution is the answer.
Question #1: Is this the final, dust-settled version?
Yes, I always use the "manual locking" anonymous subclass in the background. I
think dust will be settled when I can have a cleaner version of this functionality in
Wonder without distastefully dirtying the ERXEC factory.
Question #2: Do you always use a new EOObjectStore in your threads?
No. In have a pool of OSC's dedicated to background threads. Usually 4 to 12 in
the pool, depending on the application's needs and functionality.
WKObjectStoreCoordinator is just a simple subclass that allows me to give the
OSC a name for debugging/logging purposes, so you don't have to use that in the
pool. Just use the regular Wonder ERXOSC.
Since using this approach I have not experienced any EC deadlocks in
production. Need to decide how to implement this cleanly in Wonder some day.
Regards, Kieran
It seems your implementation depends upon it. If so, what's your philosophy on
how many you create and how long they live? I have tens of thousands of
threads running per instance per day (only a few at a time) and something tells
me creating a new OS for each is a bad idea.
Thanks,
Jon
On 12/3/09 1:31 PM, Kieran Kelleher wrote:
OK, this is the final concurrent utility code to provide manual locking ec's in
a app with safeLocking on. And just for fun and Ricardo's enjoyment of
anonymous classes ;-), the factory is an anonymous static class and its _create
method returns anonymous ERXEC's with the two methods over-riden as per Anjo's
suggestion.
/**
*AnonymousERXECfactorythatcreatesmanuallockingec'sinanappwheresafeLockingisonbydefault
*/
private static ERXEC.Factory manualLockingEditingContextFactory = new
ERXEC.DefaultFactory() {
@Override
protected EOEditingContext _createEditingContext(EOObjectStore parent) {
return new ERXEC(parent == null ? EOEditingContext.defaultParentObjectStore() :
parent) {
@Override
public boolean useAutoLock() {return false;}
@Override
public boolean coalesceAutoLocks() {return false;}
};
}
};
/**
*@returnaregularERXECwithnoauto-lockingfeatures
*/
public static EOEditingContext newManualLockingEditingContext() {
returnmanualLockingEditingContextFactory._newEditingContext();
}
/**
*Idonotwantautolockinginnon-requestthreads
*
*@paramparent
*@returnanERXECwithsafeLockingpropertiesturnedOFF.
*/
public static EOEditingContext newManualLockingEditingContext(EOObjectStore
parent) {
returnmanualLockingEditingContextFactory._newEditingContext(parent);
}
On Dec 3, 2009, at 2:54 PM, Mike Schrag wrote:
i think we're talking two different things ... if you have an empty superclass
constructor and you don't declare any constructors, then yes, there is an
implicit constructor created in your subclass that calls super (as well, if you
DO declare a constructor and there is an empty super constructor, implicitly a
super() is added to the top of your constructor). in this case, because the
anonymous subclass is declared as new ERXEC(os), it's actually calling the
ERXEC(ObjectStore) constructor (which I PRESUME java secretly added into your
subclass with a super(os) call -- this is a little different than a normal
class). However, Kieran's specifically talking about the
ERXEC.newEditingContext() factory method, which you're bypassing here by
explicitly subclassing ERXEC and instantiating the class directly.
ms
On Dec 3, 2009, at 2:45 PM, Ricardo J. Parada wrote:
Don't subclasses have an implicit super() to invoke the super class constructor?
On Dec 3, 2009, at 2:38 PM, Kieran Kelleher wrote:
True, but then I would be bypassing the EC factory, which just seems dirty, but
yes, this very good suggestion is an elegant way to do it for sure.
On Dec 3, 2009, at 2:16 PM, Anjo Krank wrote:
PS. And even the above is not perfect protection against an autolock if a
thread gets cpu execution delay between construction statement and the
ec.setCoalesceAutoLocks(false) statement. After setting safelocking props to
false, I should really check if the ec was autolocked and unlock it before
returning .... or even have an ERXEC constructor that takes a safeLocking
boolean param, but that would be two more undesired constructors ....... so
probably making isLockedInThread public (or accessible using reflection) should
do the trick.
In that case, you'd be better with
return new ERXEC(os) {
public boolean useAutoLock() {return false;}
public boolean coalesceAutoLocks() {return false;}
};
Cheers, Anjo
_______________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/lists%40lochgarman.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:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
