Re: locking problem
Re: locking problem
- Subject: Re: locking problem
- From: Nathan Dumar <email@hidden>
- Date: Mon, 20 Dec 2004 17:57:00 -0500
Ben,
That was a great explanation. Thank you for taking the time to explain
all that -- it makes much more sense now. I think that my
understanding of the reason for locking was a little off.
On Dec 19, 2004, at 7:08 PM, Ben Trumbull wrote:
First, have you actually saved the EC ? Just checking.
Yes.
Have you tried changing your fetches to have an EOFetchSpecification
with setRefreshesRefetchedObjects(true) ?
It's been quite some time since I did this code ... I think I tried
that with an EOModeler-created fetch spec, and also with the method by
the same or similar name in a display group. Many of my fetches use
the EOUtilities class, and I'd rather not rewrite them into a
conventional fetch for this method.
Also, consider trying, in Session awake() to set the EC's
setFetchTimestamp() to System.currentTimeMillis()
Hmm. I guess I can try it.
In reading a discussion thread about ERXEC recently, Anjo said that
ERXEC only locks during the "dangerous" operations, like save, fetch,
etc. So, that's what I'm doing now -- putting locks in the try
block, before any fetch or save, and unlocking right after, in the
finally block. From what I've read, this seems to be the best
solution, but I'm always open to learn more. If anyone has
suggestions, ideas, warnings, or whatever, please post.
All operations are "dangerous". Just because an operation *looks*
like it should not cause multithreading problems to you doesn't make
it safe in reality.
Oh.
But let's veer into a hypothetical land ...
The short answer is that you cannot touch anything in an EC without
semantically touching everything. Like throwing a pebble into a pond,
every operation ripples out. And just looking is dangerous too. Ask
Heisenberg or a girlfriend.
Hah! I like your sense of humor. And you make an excellent point. I
now understand why to go for the awake and sleep instead of just
locking for db transactions.
And now also Chuck:
You are reading too much into that statement regarding ERXEC. Those
were just some example situations, _not_ an exhaustive list...
Okay. I understand. If it was that easy, someone would have said so.
I think I was misunderstanding the reason for locking.
Locking is as much about transactional integrity as it is about thread
safety. It tells WebObjects "this resource is in use by this thread"
and the framework responds appropriately.
Oh. I have some vague memory of reading that when in I was in the
early stages of learning WO, before I knew what the heck that meant.
Back to session awake and sleep!
...
So, after wrestling with this in my mind for quite some time, I have
found a working solution that really, REALLY leaves me looking silly.
I studied the MultiECLockManager some more ... and added ONE measly
line.
// Removed all other comments, to improve legibility for this post
public synchronized void unregisterEditingContext(EOEditingContext
argEC) {
WeakReference correspondingReference = findReference(argEC);
if ( correspondingReference == null ) {
return;
}
if ( lockCount > 0 ) {
unregisterQueue.addObject( correspondingReference );
}
else {
weakReferences.removeObject( correspondingReference );
if ( argEC != null) { argEC.dispose(); } ///// ADDED THIS LINE /////
}
}
In my code, I replaced all of the ec.dispose with
...unregisterEditingContext(ec). I had to do a little debugging to
prevent an accumulation of ECs in the Multi (some of my unregisters
were not being called), but now it all works.
Thank you, Ben, for your patience and thorough explanation. Thank you
Kieran -- recognize the line I added? And thank you Chuck, for
clarifying what I had misunderstood.
Now to see if the server likes it ...
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