Re: EOSharedEditingContext question
Re: EOSharedEditingContext question
- Subject: Re: EOSharedEditingContext question
- From: Dov Rosenberg <email@hidden>
- Date: Thu, 03 Feb 2005 13:02:48 -0500
We use shared editing contexts to save the overhead on read only data and to
use it like a cache. When we use the shared context we always do a lock()
even for a read type operation. In cases where we are going to modify data
that has been retrieved into the shared context, we create a new editing
context and make the changes and save. We lock both the shared and the
regular context when we do.
Based on your reply I think we need to make some changes. Does the following
make any sense?
1. Instead of creating a new regular EOEditingContext, perhaps we should
make them a nested editing context with the shared editing context as the
parent. That way we make sure to get the correct state of things before we
make the changes and save to the db. Can a shared editing context have
nested editing contexts? If so, hopefully the changes will get recorded
properly by the shared context and be more efficient than what we are doing
2. If we remove the lock(), unlock() from the sharededitingcontext usage
will that start sending out the missing lock messages again? I kind of
remember we had to add the lock() calls to get rid of those.
The big qualifier for us is our app is not a typical WO app from the
perspective that our JSP tag library uses EOF but not WO components. We
really don't have WOSessions (except for the JSP Session/WOSession
integration). Our app runs as a servlet outside of the scope of the .woa
application. For the most part this works very well and we have been this
way for the past 3 years with great success.
Thanks in advance
--
Dov Rosenberg
Conviveon Corporation
http://www.conviveon.com
On 2/3/05 12:35 PM, "Chuck Hill" <email@hidden> wrote:
> Hi Dov, I don't know if this is what you are looking for, but this was
> posted a (long) while ago by Ben Trumbull:
>
> ------------
> Although an EOSharedEditingContext sounds and appears like an editing
> context, it's probably a more useful view to consider it a very special
> EOObjectStore. I prefer to call it a "read mostly object store".
>
> Several differences.
>
> First, correctly locking and unlocking an EC at the application level
> is your responsibility, regardless of whether or not you believe an
> operation is "an edit". For example, firing a fault causes side
> effects upon various caches. EOSharedEditingContexts manage their own
> locking.
>
> Second, EOSharedEditingContexts are "read mostly". Mutating EOs in
> them is complicated and inefficient.
>
> Third, regular ECs "have" one shared EC, a lot like they have a parent
> object store. This means that several regular ECs all using the same
> shared EC also use the same objects that are within the shared EC. EOs
> within a shared EC are unique instances, unlike all other EOs which
> have individual instances in each regular EC, even though they have the
> same primary key (GID).
>
> Basically, this is a memory-performance compromise. Using a shared EC
> means not only do your EOs reuse the cached row level snapshots in
> EOAccess, but they are also represented by the same Java objects. The
> down side is that shared ECs do more locking, and changing EOs within
> them is inconvenient.
>
> In summary, EOSharedEditingContext is really more about implementation
> inheritance than interface inheritance.
> ---------------------------------
>
> I suspect your problem had to do with you locking the shared EC
> yourself and the locks staying in place too long. Consider this
> hypothetical situation:
>
> Thead 1: locks EC, shared EC, performs operations which results in an
> attempt to lock object store coordinator
>
> Thread 2: performs some operation, locks object store coordinator,
> execution of operation requires operation on shared EC, shared EC
> attempts to lock itself
>
> At this point you have a deadly embrace. Thread one has the shared ec
> locked and is waiting to lock the OSC. Thread 2 has the OSC locked and
> is waiting to lock the shared EC.
>
> Chuck
>
>
> On Feb 2, 2005, at 3:42 PM, Dov Rosenberg wrote:
>
>> We recently fixed a bug in our application that was causing it to lock
>> when multiple users submitted a form request via http. After
>> scratching our heads for a long while we went to look in the ³Bible²
>> (Chuck Hill¹s Practical WebObjects great book). We came across a
>> little blurb about not locking SharedEditingContexts. When we removed
>> the lock it seems to have cleared up our deadlock problem. But we are
>> stumped as to why this caused us a headache.
>>
>> Our app uses both a sharededitingcontext and regular editing contexts
>> created doing new EOEditingContext(). We lock and unlock both the
>> shared and regular editing contexts everywhere. It seems that our
>> problem only manifested itself when we were writing to the database
>> (not reading). It was also not consistently reproducible.
>>
>> Any thoughts or comments would be appreciated.
>>
>> Thanks in advance
>>
>>
>>
>> --
>> Dov Rosenberg
>> Conviveon Corporation
>> http://www.conviveon.com
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> village.net
>>
>> This email sent to email@hidden
_______________________________________________
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