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.
WKTaskObjectStoreCoordinatorPool.java
Description: Binary data
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.
WKObjectStoreCoordinator.java
Description: Binary data
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 (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/lists%40lochgarman.com
>>
>> This email sent to li...@lochgarman.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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
