Re: Enterprise using WO

"Mark F. Murphy" <[email protected]>
Newsgroups gmane.comp.web.webobjects.general
Message-ID <p06210206beb59ee5e32c@[10.0.1.5]>
At 4:30 PM -0300 5/21/05, Alejandro M. Ramallo wrote:
>We need to scale. We do not need one connection per user. We need a 
>framework that can dynamically scale through adding connections. We 
>currently have a pool of EOObjectStoreCoordinators but is now 
>providing one OSC per user (each user is using multiple ECs...ie. 
>multiple pending transactions). This is something we are tunning 
>("n" OSCs to serve "m" users), but anyway, the issue is the same. 
>Because EOF was not redesigned to accommodate the needs of current 
>applications you end up creating multiple EOF stacks (each one with 
>a cache that gets out of sync). Even if you have two OSCs, your are 
>duplicating the cache, and remember EOF is nothing but a big cache, 
>it caches everything.

I think that's one of the major issues with EOF and having to use 
OSC's as a way to scale.  In other ORMs, you have the choice of how 
you want to cache outside of the transaction scope.  In EOF, you 
don't.  You have to live with it.

>I am now playing around with the idea of extending EODatabase and 
>override all the snapshot related methods and plug in a distributed 
>cache (OSCache, etc.) Has anyone done this? Any locking/concurrency 
>problems?

I haven't done it... but ya have to be very, very careful messing 
around with the object store.

>Change notification among instances is something you cannot escape 
>from. As you say you can use EOF based ones (David Neumman's) or 
>other non EOF.

I'm very skeptical of network based notifications.  I've just always 
used the pattern that if I need fresh data from the database, I 
should go back to the database (the original store) to get fresh data 
anyway.  The database can scale and is built to do so.

mark

-- 
---------------------------------------------------------------------------
  Mark F. Murphy, Director Software Development   <mailto:[email protected]>
  Tyrell Software Corp                            <http://www.tyrell.com>
---------------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.