Re: Locking Session.defaultEditingContext() Question
Re: Locking Session.defaultEditingContext() Question
- Subject: Re: Locking Session.defaultEditingContext() Question
- From: Dov Rosenberg <email@hidden>
- Date: Wed, 02 Apr 2008 15:04:44 -0400
- Thread-topic: Locking Session.defaultEditingContext() Question
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@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden