Re: locking problem
Re: locking problem
- Subject: Re: locking problem
- From: Nathan Dumar <email@hidden>
- Date: Sun, 19 Dec 2004 17:50:43 -0500
I think I didn't make myself clear ...
On Dec 19, 2004, at 4:48 PM, Ben Trumbull wrote:
It really looks like you still have a reference an EO that used to be
in the EC after calling reset.
I'll check my code for this, but I don't think I did that.
Trying to reuse an EO after calling reset() or doing anything at all
with an EC or any of its ex-EOs after calling dispose() is very very
very BAD.
This is what I mean by using the EC again:
// this works
// did stuff in ec
ec.dispose();
ec = new EOEditingContext();
anObject = EOUtilities.createAndInsertInstance(ec, "object"); // or
whatever other activities
If I replace dispose with reset, I get the previously mentioned error.
I guess it would be more accurate to say that I can't re-use a handle?
or pointer? if I use reset.
Keeping EOs around means there is still a hard reference to your EC.
So your ECs won't get garbage collected, so your app will leak a lot
of memory.
I'm not sure this applies here. How do you mean keeping them around?
If edits in other ECs don't show up until you've disposed a different
EC, then you're doing something significantly wrong.
It might be best to step back from the dispose issue and explain the
higher level problem.
Okay, I can try that. I make an EC and I do a bunch of stuff in it
(making objects, saving, etc). If I don't dispose the EC when I'm done
with it, and I move on and do other stuff in other components, then
other editing contexts from other sessions can't see the newly created
objects (can't see the info in the database) until that first ec
finally gets garbage collected. Fetches for other ECs in other
sessions will not return the new objects as long as the EC that created
them still exists (aka stale data). Garbage collecting the unused EC
takes a long time; I need the info to be made immediately available.
The best way I've found is to dispose the EC when I'm done using it.
Sometimes I do this more than once in a single component, just to make
sure the objects are released and other ECs in other sessions can see
them (in the database).
I'm not trying to reference an object after its editing context has
been deleted. I'm trying to pull the object from the database (fetch)
into a new editing context (in a different session) for a different
user. WO doesn't want to do that unless the editing context that
created the object is disposed or garbage collected. I opt for the
faster of the two.
Now, when using MultiECLockManager, I can't dispose the EC because when
the session goes to sleep, Multi tries to unlock the non-existent EC
(deployment only). So, I'll have to forego using the cool tool and
just lock and unlock around the times when I fetch or save.
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.
Thanks,
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