Menu
▾
▴
Re: [Wonder-disc] Wonder locking and deadlock
|
From: Chuck H. <ch...@gl...> - 2007-05-01 21:19:12
|
On May 1, 2007, at 1:38 PM, Steven Mark McCraw wrote:
> Hi Chuck,
>
> How is that accomplished?
objectStoreCoordinator.lock() usually. :-P
> That is, when I lock any editing context, does it lock it's parent
> automatically (and hence lock the EOObjectStoreCoordinator if it
> isn't a nested ec)?
No, the frameworks lock it and you can lock it manually as well.
> Should I just search my code for all invocations of "lock()" and
> make sure there is a corresponding finally statement that unlocks
> for each one?
That is always a good idea.
> Or are there more subtle ways to lock the EOObjectStoreCoordinator?
It get locked whenever any operation goes deeper into EOF than the
current EC. I see two possibilities:
1. Some other thread you are not showing us has it locked and is
blocked trying to lock something else. Check those thread dumps
carefully!
2. Some thread locked it (or did something that locked it) and then
threw an exception and died before unlocking it. This will be hard
to track down. Check the app log for exceptions.
Chuck
>
> On May 1, 2007, at 4:29 PM, Chuck Hill wrote:
>
>> Something in your code is locking EOObjectStoreCoordinator and not
>> unlocking it.
>>
>> Chuck
>>
>>
>> On May 1, 2007, at 1:20 PM, Steven Mark McCraw wrote:
>>
>>> Hi Chuck,
>>>
>>> Here is the thread dump:
>>>
>>> [1] java.lang.Object.wait (native method)
>>> [2] java.lang.Object.wait (Object.java:429)
>>> [3] com.webobjects.foundation.NSRecursiveLock.lock
>>> (NSRecursiveLock.java:72)
>>> [4] com.webobjects.eocontrol.EOObjectStoreCoordinator.lock
>>> (EOObjectStoreCoordinator.java:466)
>>> [5] com.webobjects.eocontrol.EOEditingContext.lockObjectStore
>>> (EOEditingContext.java:4,675)
>>> [6] com.webobjects.eocontrol.EOEditingContext.objectWillChange
>>> (EOEditingContext.java:2,765)
>>> [7] er.extensions.ERXEC.objectWillChange (ERXEC.java:733)
>>> [8]
>>> com.webobjects.eocontrol.EOObserverCenter.notifyObserversObjectWillC
>>> hange (EOObserverCenter.java:433)
>>> [9] com.webobjects.eocontrol.EOCustomObject.willChange
>>> (EOCustomObject.java:271)
>>> [10] com.webobjects.eocontrol._EOMutableKnownKeyDictionary
>>> $Initializer$_GenericRecordBinding.setValueInObject
>>> (_EOMutableKnownKeyDictionary.java:527)
>>> [11]
>>> com.webobjects.eocontrol.EOCustomObject.takeStoredValueForKey
>>> (EOCustomObject.java:1,778)
>>> [12] er.extensions.ERXGenericRecord.takeStoredValueForKey
>>> (ERXGenericRecord.java:929)
>>> [13] _EmailScheduler.setEmailTypeParameter
>>> (_EmailScheduler.java:56)
>>> [14] PackingSlip.updateStatusForPackingSlipWithKeyAndTracking
>>> (PackingSlip.java:467)
>>> [15] DirectAction.shippingUpdateAction (DirectAction.java:206)
>>> [16] sun.reflect.GeneratedMethodAccessor155.invoke (null)
>>> [17] sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> [18] java.lang.reflect.Method.invoke (Method.java:324)
>>> [19] com.webobjects.appserver.WODirectAction.performActionNamed
>>> (WODirectAction.java:128)
>>> [20] DirectAction.performActionNamed (DirectAction.java:43)
>>> [21]
>>> com.webobjects.appserver._private.WOActionRequestHandler._handleRequ
>>> est (WOActionRequestHandler.java:240)
>>> [22]
>>> com.webobjects.appserver._private.WOActionRequestHandler.handleReque
>>> st (WOActionRequestHandler.java:145)
>>> [23] er.extensions.ERXDirectActionRequestHandler.handleRequest
>>> (ERXDirectActionRequestHandler.java:82)
>>> [24] com.webobjects.appserver.WOApplication.dispatchRequest
>>> (WOApplication.java:1,306)
>>> [25] er.extensions.ERXApplication.dispatchRequest
>>> (ERXApplication.java:1,102)
>>> [26] com.webobjects.appserver._private.WOWorkerThread.runOnce
>>> (WOWorkerThread.java:173)
>>> [27] com.webobjects.appserver._private.WOWorkerThread.run
>>> (WOWorkerThread.java:254)
>>> [28] java.lang.Thread.run (Thread.java:552)
>>>
>>> PackingSlip.java line 467 is the one denoted by the "->" in my
>>> original email.
>>>
>>>
>>> The other place threads seem to be stuck have the following stack
>>> trace:
>>>
>>> [1] java.lang.Object.wait (native method)
>>> [2] java.lang.Object.wait (Object.java:429)
>>> [3] com.webobjects.foundation.NSRecursiveLock.lock
>>> (NSRecursiveLock.java:72)
>>> [4] com.webobjects.eocontrol.EOObjectStoreCoordinator.lock
>>> (EOObjectStoreCoordinator.java:466)
>>> [5] com.webobjects.eocontrol.EOEditingContext.lockObjectStore
>>> (EOEditingContext.java:4,675)
>>> [6] com.webobjects.eocontrol.EOEditingContext._dispose
>>> (EOEditingContext.java:1,047)
>>> [7] com.webobjects.eocontrol.EOEditingContext.dispose
>>> (EOEditingContext.java:996)
>>> [8] er.extensions.ERXEC.dispose (ERXEC.java:574)
>>> [9] com.webobjects.appserver.WOSession.terminate
>>> (WOSession.java:560)
>>> [10] er.extensions.ERXSession.terminate (ERXSession.java:547)
>>> [11] JDBCSession.terminate (JDBCSession.java:55)
>>> [12] Ack.sleep (Ack.java:35)
>>> [13] com.webobjects.appserver.WOComponent._sleepInContext
>>> (WOComponent.java:1,015)
>>> [14]
>>> com.webobjects.appserver.WOContext._putAwakeComponentsToSleep
>>> (WOContext.java:606)
>>> [15]
>>> com.webobjects.appserver._private.WOActionRequestHandler._putCompone
>>> ntsToSleepInContext (WOActionRequestHandler.java:419)
>>> [16]
>>> com.webobjects.appserver._private.WOActionRequestHandler._handleRequ
>>> est (WOActionRequestHandler.java:310)
>>> [17]
>>> com.webobjects.appserver._private.WOActionRequestHandler.handleReque
>>> st (WOActionRequestHandler.java:145)
>>> [18] er.extensions.ERXDirectActionRequestHandler.handleRequest
>>> (ERXDirectActionRequestHandler.java:82)
>>> [19] com.webobjects.appserver.WOApplication.dispatchRequest
>>> (WOApplication.java:1,306)
>>> [20] er.extensions.ERXApplication.dispatchRequest
>>> (ERXApplication.java:1,102)
>>> [21] com.webobjects.appserver._private.WOWorkerThread.runOnce
>>> (WOWorkerThread.java:173)
>>> [22] com.webobjects.appserver._private.WOWorkerThread.run
>>> (WOWorkerThread.java:254)
>>>
>>> JDBCSession line 55 (line 11 of the stack trace) is simply
>>> calling super.terminate:
>>>
>>> super.terminate();
>>>
>>>
>>> On May 1, 2007, at 4:08 PM, Chuck Hill wrote:
>>>
>>>> That is an odd place to get a deadlock. What is the thread dump
>>>> of this thread and the one(s) that it is locked with?
>>>>
>>>> Chuck
>>>>
>>>> On May 1, 2007, at 1:05 PM, Steven Mark McCraw wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm using automatic locking in an application, and have it
>>>>> configured as follows:
>>>>>
>>>>> er.extensions.ERXApplication.useEditingContextUnlocker=true
>>>>> er.extensions.ERXEC.defaultAutomaticLockUnlock=true
>>>>> er.extensions.ERXEC.useSharedEditingContext=false
>>>>> er.extensions.ERXEC.defaultCoalesceAutoLocks=true
>>>>>
>>>>> I just started using it, and I've begun to get deadlocking in
>>>>> my application. I attached a debugger and took a thread dump,
>>>>> and it seems to be happening in the following block of code:
>>>>>
>>>>> if ( tracking != null && tracking.length() > 0 ) {
>>>>> EOEditingContext ec = ERXEC.newEditingContext();
>>>>> NSTimestamp now = new NSTimestamp();
>>>>> ec.lock();
>>>>> try {
>>>>> EmailScheduler shippingNotice = (EmailScheduler)
>>>>> EOUtilities
>>>>> .createAndInsertInstance( ec, "EmailScheduler" );
>>>>> -> shippingNotice.setEmailTypeParameter( "Customer
>>>>> Shipping Notification" );
>>>>> shippingNotice.setSendDate( now );
>>>>> shippingNotice.setTableName( "PackingSlip" );
>>>>> shippingNotice.setUniqueIdentifier( result.getString
>>>>> ( "PACKING_SLIP_ID" ) );
>>>>> ec.saveChanges();
>>>>> } finally {
>>>>> ec.unlock();
>>>>> }
>>>>> }
>>>>>
>>>>> The threads are waiting at "shippingNotice.setEmailTypeParameter
>>>>> ( "Customer Shipping Notification" );", which is the first time
>>>>> I alter the EO in the locked editing context.
>>>>>
>>>>> The manual locking and unlocking of the editing context is just
>>>>> code that I have had in for quite some time, but this piece of
>>>>> code just started to seem problematic after adding automatic
>>>>> locking from Project Wonder. So my question is, if I'm letting
>>>>> Wonder handle all of my locking/unlocking for me, configured as
>>>>> shown above, is it actually problematic to continue to lock/
>>>>> unlock myself? Am I getting into some kind of race condition
>>>>> where both my code and Wonder's automatic locking capabilities
>>>>> are fighting for a lock on an editing context? Should I go
>>>>> through and remove all lock/unlock statements in my code now
>>>>> that I'm using Wonder's locking mechanism? Or is there some
>>>>> other issue here that I'm missing?
>>>>>
>>>>> Thanks in advance,
>>>>> Mark
>>>>> ------------------------------------------------------------------
>>>>> -------
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>> http://sourceforge.net/powerbar/db2/
>>>>> _______________________________________________
>>>>> Wonder-disc mailing list
>>>>> Won...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/wonder-disc
>>>>
>>>> --
>>>>
>>>> Practical WebObjects - for developers who want to increase their
>>>> overall knowledge of WebObjects or who are trying to solve
>>>> specific problems.
>>>> http://www.global-village.net/products/practical_webobjects
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>>
>> Practical WebObjects - for developers who want to increase their
>> overall knowledge of WebObjects or who are trying to solve
>> specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>
>
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
|