Re: Unable to release locks when using MultiECLockManager
Re: Unable to release locks when using MultiECLockManager
- Subject: Re: Unable to release locks when using MultiECLockManager
- From: Owen McKerrow <email@hidden>
- Date: Wed, 30 Apr 2008 13:30:16 +1000
The were only 2 of them.
One was .....
ec.lock();
ec.revert();
ec.unlock();
The Other was making a display group ( all be it my tweaked version
of one ).
getEc().lock();
rfcdDisplayGroup = new OMDisplayGroup( 10, 1, "RFCD", getEc
(), null, null );
EODatabaseDataSource dataSource = (EODatabaseDataSource)
rfcdDisplayGroup.dataSource( );
dataSource.setFetchSpecificationByName( "getAll" );
rfcdDisplayGroup.qualifyDataSource( );
getEc().unlock();
So no I don't think either of these would cause an issue.
There is one method in the app that creates its own EOEditingContext
which is not registered with the MultiECLockManager, but it a
ec.unlock() in the finallly() section of its try catch block.
finally{
if ( ec != null ) {
ec.unlock();
ec.dispose();
}
}
I checked yesterdays logs and it occurred 31 times and in fact in a
couple of places its closely followed by a ....
2008,04.29 15:54:14,768 DEBUG [Finalizer] (Log.NSLogDebug:1546
appendln) - decrementSnapshotCountForGlobalID:
com.webobjects.eoaccess.EODatabase
com.webobjects.eoaccess.EODatabase@18fb397 -- is unable to decrement
snapshot count for object with global ID _EOIntegralKeyGlobalID
[External (java.lang.Long)10194] - count is already 0 or this
snapshot doesn't exist
2008,04.29 15:54:14,769 DEBUG [Finalizer] (Log.NSLogDebug:1546
appendln) -
java.lang.RuntimeException: Unable to decrement snapshot count for
object with global ID _EOIntegralKeyGlobalID[External (java.lang.Long)
10194] - count is already 0 or this snapshot doesn't exist
at
com.webobjects.eoaccess.EODatabase.decrementSnapshotCountForGlobalID
(EODatabase.java:1150)
at
com.webobjects.eoaccess.EODatabaseContext.editingContextDidForgetObjectW
ithGlobalID(EODatabaseContext.java:3752)
at
com.webobjects.eocontrol.EOObjectStoreCoordinator.editingContextDidForge
tObjectWithGlobalID(EOObjectStoreCoordinator.java:665)
at
com.webobjects.eocontrol.EOEditingContext.editingContextDidForgetObjectW
ithGlobalID(EOEditingContext.java:3921)
at com.webobjects.eocontrol.EOEditingContext._forgetObject
(EOEditingContext.java:1536) at
com.webobjects.eocontrol.EOEditingContext._dispose
(EOEditingContext.java:1123)
at com.webobjects.eocontrol.EOEditingContext.finalize
(EOEditingContext.java:1178)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
This concerns me, as from the stack trace both problems occur deep in
the bowls of webobjects, which from the looks of things is inside a
try/catch block, which logs out the error but doesn't then throw it.
It seems to me that its almost treating these errors as warnings, not
real exceptions. Or am I misunderstanding what's going on here ?
Owen McKerrow
WebMaster, emlab
Ph : +61 02 4221 5517
http://emlab.uow.edu.au
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
People who prefer typing to pointing then seem to prefer acronyms to
save typing :-)
-Denis Stanton, On people using Command Line Interfaces
On 30/04/2008, at 1:08 PM, Art Isbell wrote:
On Apr 29, 2008, at 4:47 PM, Owen McKerrow wrote:
I remember discussing MultiECLockManager on list last year with
chuck Hill ( http://lists.apple.com/archives/Webobjects-dev/2007/
Apr/msg00609.html ) who pointed out that he'd tweaked
MultiECLockManager inside his GVCWOExtensions framework. So thats
where this version comes from.
Ah, well it's not identical to the original version which is what
I'm using, so I'll let Chuck comment.
The header in my version of MultiECLockManager makes no mention
of sending a MultiECLockManager object an unlock() message in
Session.terminate(), so I don't do this. However, if you do this
and there's no matching lock() invocation, MultiECLockManager
will throw an exception (maybe MultiECLockManager.isLocked()
would prevent this from occurring). You're not catching this
exception in terminate() and aren't invoking super.terminate() in
a finally block, so if an exception is thrown, super.terminate()
won't be invoked which can cause nasty problems.
So at minimum I should shift this into a try{} catch{} block ?
Theoretically, the condition that would result in unlock() being
invoked should be prevented by the isLocked() test, so an uncaught
exception may be unlikely. But I always include super.terminate()
in a finally clause because of the importance of it being invoked.
Your original problem appears to be caused by your code not
unlocking an editing context somehow. You've found a couple of
editing contexts that weren't being manually locked/unlocked
inappropriately. Might this have caused the Finalizer problem?
Aloha,
Art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40uow.edu.au
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden