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.
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. 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 _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
