On Apr 29, 2008, at 6:25 PM, Owen McKerrow wrote:
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();
}
I wrap anything other than super.... in try...catch(Throwable), just
in case.
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();
}
That looks like my code, but be aware that if you have other bugs that
result in ecLockManager().unlock() not getting called and session
timing out, that this will throw. Again, better to wrap in a
try...catch (Throwable) block.
Chuck
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/chill%40global-village.net
This email sent to [EMAIL PROTECTED]
--
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
_______________________________________________
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]
