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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
