On Apr 2, 2008, at 12:04 PM, Dov Rosenberg wrote:
Anywhere we created a new EOEditingContext - we replaced it with the
LockScreamingEditingContext so we can track lock and unlocks
properly. All
of our locks and unlocks are in TRY/FINALLY methods. Not a perfect
solution
but it certainly helped clean up our stability issues.
What the LockScreamingEditingContext won't tell you is when you are
using the EC but it is NOT locked. Unless you are doing the locking
using ERXEC and friends or the MultiECLockManager (whatever its real
name is), there is a very good chance that you are using unlocked
editing contexts at some point.
I removed the lock we were doing on a session based default editing
context
and it fixed the issue we were having. Definitely not a good idea to
lock
the default editing context.
I agree. :-)
Chuck
Dov Rosenberg
On 4/2/08 1:29 PM, "Chuck Hill" <[EMAIL PROTECTED]> wrote:
On Apr 1, 2008, at 8:17 AM, Dov Rosenberg wrote:
I have been tracking down a strange error in our app.
java.lang.IllegalStateException: There is no database snapshot
available for the object
In a lot of places we use a new EditingContext instead of the
default Editing Context for the session. When we use a new editing
context we have been very careful to lock and unlock before and
after use.
How? What do you use? Where / how do you do this?
In some places we use the session default EditingContext (we are
probably going to stop doing that in the future). A couple of
questions come to mind:
• I have read that it is not necessary to lock the session default
EditingContext because EOF will automanage it. What happens if it
does get manually locked? The error above was thrown when trying to
do an ec.lock() on a Session.defaultEditingContext().
I'd really go a long way to avoid locking and unlocking the default
EC. This can lead to serious problems, especially around session
termination.
• What physically happens when an EC is locked? It seems it is some
sort of reference counter. In an earlier post Chuck mentioned that
locking the EODatabaseContext will prevent fetches/saves from
occurring, what happens when an EC is locked?
Mostly it prevents other threads from updating its state (e.g. when
an
EC in those threads saves changes to objects in this EC). The
changes
are queued for later processing.
• Is there any compelling reason to use the session default editing
context? We aren’t using Project Wonder (yet)
I use them for things whose lifetime matches the session: logged in
user, their permissions, etc.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
