Hi Art,
Thats sounds like word for word the practices that we follow.
Although I did just double check the code to make sure and I found a
couple of places which had manual lock/unlock's in them which should
not have.
From Session.java
public void awake()
{
ecLockManager().lock();
super.awake();
.....
public void sleep()
{
// Need to check as this gets called after terminate() when logging
out
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
super.sleep();
}
public void terminate()
{
// Need to make sure this is unlocked so that editing
contexts nested in the defaultEditingContext
// don't hold locks on it when it gets disposed
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
super.terminate();
}
Owen McKerrow
WebMaster, emlab
Ph : +61 02 4221 5517
http://emlab.uow.edu.au
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
'The test of a first-rate intelligence is the ability to hold two
opposed ideas in the mind at the same time and still be able to
function.'
-F.Scott Fitzgerald,
On 30/04/2008, at 10:56 AM, Art Isbell wrote:
On Apr 29, 2008, at 2:24 PM, Owen McKerrow wrote:
Sorry all, I should have specified that further. Has anyone seen
it whilst using MultiECLockManager ?
No, but you must use MultiECLockManager correctly. Are you
invoking MultiECLockManager.unlock() in Session.sleep() before any
statement that might throw an exception that would result in
MultiECLockManager.unlock() not being invoked?
I let MultiECLockManager handle the locking/unlocking of all
editing contexts that aren't WOSession's defaultEditingContext()
and that aren't stored in a local variable (i.e., the scope editing
context is limited to the method in which it is created). I lock/
unlock local editing contexts myself ensuring that they're unlocked:
EOEditingContext ec = new EOEditingContext();
ec.lock();
try {
// Do stuff
}
finally {
ec.unlock();
}
This approach hasn't resulted in any illegal lock usage exceptions.
Aloha,
Art
_______________________________________________
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/owen%
40uow.edu.au
This email sent to [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
