Re: _eoForGID exception (was: java 1.4 solaris memory issue)
Re: _eoForGID exception (was: java 1.4 solaris memory issue)
- Subject: Re: _eoForGID exception (was: java 1.4 solaris memory issue)
- From: Kaj Hejer <email@hidden>
- Date: Wed, 17 Sep 2003 14:23:15 +0200
At 22:30 +0200 16-09-2003, Kaj Hejer wrote:
At 14:54 -0700 11-04-2003, Cliff Tuel wrote:
> Earlier today there was a note about a memory bug associated with Java
1.4 on Solaris. Is the Java 1.4/Solaris memory allocation/freeing issue
specific only to WebObject 5.1.x on Solaris with Java 1.4 or is it a
more general Java 1.4 bug on Solaris? Does WebObject 5.2.1 address the
memory issue?
If you're referring to the post by Kaj Hejer <email@hidden>, he
clarified for me off-list that he got the _eoForGID exception with 5.2.1 on
Java 1.3.1, **not** 1.4.x. He was merely asking if upgrading to 1.4.x would
help. Their temporary solution was to revert to WebObjects 5.1.3.
Hi!
It is me with the _eoForGID issue again :)
Hi!
Until yesterday I was convinced that if the parent ec was locked its
child ecs would be automaticly locked too.
That is not correct!
After locking my child ecs it seems that I'm not able to reproduce
this issue. I have to test this a little more to convince myself that
this issue really is gone, but so far it looks good.
See the mail bellow.
--- begin forwarded text
Date: Wed, 17 Sep 2003 14:19:55 +0200
To: email@hidden
From: Kaj Hejer <email@hidden>
Subject: Re: more on prepareForSaveWithCoordinator error
At 16:02 -0500 16-09-2003, Jonathan Rochkind wrote:
At 10:23 PM 9/16/2003 +0200, Kaj Hejer wrote:
I use session.defaultEditingContext and a childEditingContext with
this context as its parent.
I know EOF is locking the session.defaultEditingContext for me, and
from what I have understood this also goes editingContexts which
has this ec as their parents.
Aha! This is not true. It was subject to lots of debate on the
list, but the general consensus these days (and Apple engineers who
work on the code agree), is that you still need to manually lock and
unlock your nested ECs. I bet the lack of proper locking is (at
least in part) responsible for your problems (and mine). It's
possible that properly locking them will make your problem go away.
Thank you Jonathan, Ben and Chuck! This was new to me! Still learning
after all these years ;-) Well... isn't that what life is all about :)
When running my jwebunit suite 50 times before posting about this
issue yesterday I got 2 or 3 _eoForGID exceptions I think.
(jwebunit is great tool for testing, see http://jwebunit.sourceforge.net/ :)
Now I have added code to lock and unlock my child ec and now I don't
get any of these exceptions.
I don't dare to trust this issue is solved yet ;-) so I will run
these tests a few more times. Stay tuned! I will let you know the
results of the testing.
btw: is it possible to find out if a ec is locked or not? Should
there have been a isLocked method in EOEditingContext?
Jonathan: If you some time should try locking child ECs in code where
you got this _eoForGID is would be very interessting to see if
locking the childECs solves your problems too.
I wrote a class, which I've been using in production for some time
now without problems, which provides a very convenient way for you
to lock and unlock your ECs, whether nested or peer. I'll go put it
on WOcode right now. If you (or anyone) ends up using it, I'd be
interested to hear how well it worked.
http://wocode.com/cgi-bin/WebObjects/WOCode.woa/wa/ShareCodeItem?itemId=301
Thanks for posting this code! I have added my own locking logic for
this application but maybe we will try the MultiECLockManager in some
other app :)
-Kaj :)
--- end forwarded text
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.