Re: Shared EC

At 13:15 -0300 2/7/03, <[email protected]> wrote:
>What is the utility of using Shared EC?
>
>I dont get the difference between a Shared EC and a EC at 
>application level wich i manage not to be edited.

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.
-- 

-Ben