Re: EOSharedEditingContext question
Re: EOSharedEditingContext question
- Subject: Re: EOSharedEditingContext question
- From: Chuck Hill <email@hidden>
- Date: Thu, 3 Feb 2005 09:35:26 -0800
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
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden