On Jul 6, 2008, at 6: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();
}
}
This is from my WOSession sub-class (very old code that I have not
touched in years):
public void awake()
{
try
{
ecLockManager().lock();
}
catch(Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in
WOSession.awake() calling ecLockManager.lock(): " + t);
}
super.awake();
}
public void sleep()
{
// Need to check as this gets called after terminate() when
logging out
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
try
{
ecLockManager().unlock();
}
catch (Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in
WOSession.sleep() calling ecLockManager.unlock(): " + t);
}
}
}
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())
{
try
{
ecLockManager().unlock();
}
catch (Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in
WOSession.terminate() calling ecLockManager.unlock(): " + t);
}
}
}
super.terminate();
}
Your implementation looks fine to me.
Should we be using unregisterEditingContext instead of unlock() ? If
not why/when should you use unregisterEditingContext ?
I very rarely use it. I think I used it once where it was possible
that two ECs had been created where I only needed one. This was used
to quickly discard the one that was not needed.
Chuck
On 04/07/2008, at 3:53 PM, Lachlan Deck wrote:
On 04/07/2008, at 2:54 PM, Chuck Hill wrote:
On Jul 3, 2008, at 9:30 PM, Lachlan Deck wrote:
Perhaps a parent ec? Is there any child ecs involved here?
I don't recall terribly clearly now as it's been a while... but I
remember that for some strange reason an object that I had in the
shared editing context didn't localize into the ec that I wanted
when attempting to set the relationship - but there was no
exception until saveChanges. It might have been when said ec
didn't have its sharedEc == null, or invalid locking or something.
I recall, when trying to track it down, mucking around with
temporarily unlocking shared ec locks and stuff. But I think it
turned out to be ensuring that the ec in question didn't properly
set its shared ec to null (I think).
Sorry I don't recall much more than that.
Ah, there you go on about the shared EC again. :-P
Someone says it can't/shouldn't be used... just can't help
myself... Shared ec, VI, ... I'm just waiting for the next
suggestion :-)
I had not considered the SEC being involved. That puts a new twist
on things.
Owen, are you using the SEC?
Bear in mind that you *might* be using it unintentionally. e.g.,
you've declared in your model 'share objects' and/or you're not
nullifying your ec's shared ec (which is the usual for your default
session context IIRC).
with regards,
--
Lachlan Deck
_______________________________________________
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/owen%40uow.edu.au
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 ([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]
