Re: locking problem
Re: locking problem
- Subject: Re: locking problem
- From: Kieran Kelleher <email@hidden>
- Date: Sun, 19 Dec 2004 09:00:25 -0500
Nathan,
I am not using MultECLock manager, but note that dispose DOES call
unlock on an EC, so as shown below, setting your handle to null after
calling dispose will ensure it gets garbage collected and checking for
null handle before unlocking can prevent you unlocking a disposed EC:
For example in this code, I dispose and set to null my EC
/** Disposes of the current taskEditingContext */
public void terminateTaskEditingContext() {
if (taskEditingContext != null) {
taskEditingContext.dispose();
taskEditingContext = null;
}
}
and in Session sleep, I only unlock it if it still exists:
public void sleep() {
super.sleep();
// If taskEditingContext exists, unlock it
if (taskEditingContext != null) {
taskEditingContext.unlock();
}
}
and in session awake:
public void awake() {
super.awake();
// If taskEditingContext exists, lock it
if (taskEditingContext != null) {
taskEditingContext.lock();
}
}
Regards, Kieran
________________________________________________________________
Dev Config = OS X 10.3.5 / Java 1.4.2_05 / WO 5.2.3 / XCode v1.5 /
MySQL 4.0.20 / Connector-J 3.0.11
Deploy Config = OS X 10.3.5 Server / Java 1.4.2_05 / WO 5.2.3 / MySQL
4.0.20 / Connector-J 3.0.11
My Blog: http://webobjects.webhop.org/
On Dec 18, 2004, at 7:30 PM, Nathan Dumar wrote:
Thanks for some input, Ben.
On Dec 18, 2004, at 6:45 PM, Ben Trumbull wrote:
At 5:58 PM -0500 12/18/04, Nathan Dumar wrote:
In my app, I'm using MultiECLockManager. I'm locking and unlocking
in session
awake and asleep. I have no direct actions. On my dev machine, I
can
ec.dispose() in a component without a problem. On the deployment
machine
disposing an EC causes the following error:
java.lang.IllegalStateException: Illegal Lock usage: unlock() called
without a
lock()
I believe this is known issue in WO. The sequence of events is:
1) Session locks its EC at the beginning of the event loop
2) User code invokes dispose() on the Session's EC
3) Session unlocks its EC at the end of the event loop, which no
longer exists
4) Boom
So why no Boom on my dev machine? It's exactly the same code.
Don't call dispose() on the Session's default editing context.
I've never done that, but somehow I knew that would be a Very Bad Idea.
All in all, you shouldn't need to call dispose(). When the EC is
finalized by the garbage collector, the exact same thing will happen.
The only difference is when.
And sometimes that can be a very big difference. Dispose is my remedy
for stale data, and has worked well so far. I need the edits done in
an editing context to be immediately available to ECs in other
sessions, and for some reason the other sessions' ECs can't see the
new stuff until the creating EC is GC'd or disposed. If I don't
dispose, my users will have to wait around for a half hour to get
updates. Not good. I depend on having the data immediately
available.
If you find you must dispose() the EC, but get bitten by this bug,
try using reset() and letting the GC do dispose().
Hmm... Looks like it could work. I'll have to try it out. If it
releases new objects so that other ECs can see them, then it will
satisfy.
If this isn't your session's default EC, then it's not the problem
I'm describing here.
Of course, if it's your own EC, and you unlock it in sleep() after
you've called dispose() then you've just recreated the problem in
your own code.
It's not the default EC, and apparently I have recreated it in my own
code, but only when deployed. Why does this not cause problems in my
development environment? In looking at the code for
MultiECLockManager.unlock(), there's this (and a bunch of other stuff,
but this is what's important for discussion):
NSArray allECs = strongReferences.allValues();
for ( int i = allECs.count() - 1; i >= 0; i--) {
EOEditingContext ec = (EOEditingContext)
allECs.objectAtIndex( i );
ec.unlock();
}
If I've disposed an EC (which means it's all gone, right?) then when
allECs gets loaded with an array of ECs to unlock, the disposed EC
should not even be in there. It should not be in the array of ECs
that are unlocked, so there should be no problem. This seems to be
the case in my development environment, since I get no errors
whatsoever. It's only in deployment that I get errors. The same code
should work the same in both development and deployment.
So ... is reset() my magic bullet? Or unlock-unregister-dispose? Or
something else?
Thanks again for your help, Ben.
Take care,
Nathan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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