Re: locking problem
Re: locking problem
- Subject: Re: locking problem
- From: Nathan Dumar <email@hidden>
- Date: Sat, 18 Dec 2004 19:30:56 -0500
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:
This email sent to email@hidden