Re: Back To Basics : Databases Active Editing Context
Re: Back To Basics : Databases Active Editing Context
- Subject: Re: Back To Basics : Databases Active Editing Context
- From: Art Isbell <email@hidden>
- Date: Sun, 06 Jul 2008 17:58:29 -1000
On Jul 6, 2008, at 3:49 PM, Owen McKerrow wrote:
OK so we think we probably screwed up implementing MultiLockManager
somehow, so heres a couple of more questions to make sure all of our
bases are covered :
In Session's sleep we have ( terminate looks exactly the same except
of course its for terminate )
public void sleep()
try {
synchronized (ecLockManager) {
if (ecLockManager().isLocked()) {
ecLockManager().unlock();
}
}
}
finally {
super.sleep();
}
}
Should we be using unregisterEditingContext instead of unlock() ? If
not why/when should you use unregisterEditingContext ?
For several years, I've been using the original MultiECLockManager
that doesn't have the isLocked() method that someone (Chuck?) added.
I believe there's not much difference otherwise.
I've never invoked unregisterEditingContext(). After an editing
context has been garbage-collected, it will be unregistered
automatically the next time lock() is invoked. So it's not necessary
to unregister. When you know that you've used a registered editing
context for the last time, I suppose you could unregister it, but it
won't actually be unregistered until unlock() is invoked in sleep().
There might be a situation where you'd unregister an editing context
without unreferencing it, but I've never done that.
Aloha,
Art
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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