Re: Practical EditingContext Design Question

On Feb 16, 2006, at 7:15 AM, [email protected] wrote:

>
> Hi,
>
> After (re)reading the (famous) "Practical WebObjects" book

Infamous?  :-P

> and paying attention to the CooperatingEditingContext, I'd like to  
> implement a better solution for our portal.
>
> In a portal, there is two types of users :
> - the readers,
> - the contributors
>
> The readers read informations (from the databases) displayed on pages
> The contributors do the same AND they create/modify/delete objects
>
> Actually (before reading the book), we use the  
> session.defaultEditingContext for each user (session)
>
This I would tend to avoid.


> But it means that for each user we will have a (local) copy of the  
> enterprise objects fetched by the visitor. If we have a lot of  
> users (and that's the case) we need more and more memory...
>
Hold on a second.  Editing contexts don't hold onto fetched objects  
unless they have been modified.  It is the pages that hold onto the  
fetched objects.  To reduce memory usage, reduce your page cache  
size.  This way, the pages will be discarded and garbage collected  
sooner and the memory freed.  If the read only pages don't  have any  
component action URLs on them, you can even override session.savePage 
() and NOT call super.savePage for them thus avoiding the page cache  
entirely.

Another useful strategy is to keep the session timeout low for  
readers (say 5 or 10 minutes) and increase this (say to 60 minutes)  
when the user becomes a contributor (logs in?).  This way, abandoned  
sessions will be recycled quicker and further reduce memory usage.

Finally, make as many of your components stateless as possible to  
reduce memory load from multiple copies.

We have released our CMS as Open Source (http://sourceforge.net/ 
projects/gvcsitemaker).  It addresses these issues, you might find it  
useful reading (though it is a rather large codebase).  We have been  
quite successful at limiting memory usage.


> But finally isn't it possible to :
> - use only one editing context for all the readers (except forl  
> informations like authentifcation that will still be in the  
> defautEditingContext)
> AND
> - one CooperativeEditingContext (thank's to Sacha and Charles) each  
> time a contributor is making change. After each contribution, we  
> just need to populate the changes to the global one editing context.
>
> Is it a good solution ?
>
Possibly not.  You really do want to have the global / application  
wide editing context locked when each session accesses it.  If it is  
locked then other sessions can't access it and you can't do  
concurrent request dispatching.  In a mostly read only app like this,  
concurrent request dispatching is a corner stone in good  
scalability.  You might use a pool of application level editing  
contexts, and have the session check one out when it starts to  
dispatch (in awake) and check it back in in sleep.  I've not tried  
this, but it seems like a workable solution.  That way, you would  
only have as many read only editing contexts as you had concurrent  
dispatches.

> In the book, different king of EditingContext are explained but  
> wich one do we need to use for the readers ?  
> DefaultShareEditingContext ? Other ?
>
Peer / ordinary editing context would be my choice.

Chuck

-- 
Coming in 2006 - an introduction to web applications using WebObjects  
and Xcode     http://www.global-village.net/wointro

Practical WebObjects - for developers who want to increase their  
overall knowledge of WebObjects or who are trying to solve specific  
problems.    http://www.global-village.net/products/practical_webobjects