Re: Practical EditingContext Design Question
Re: Practical EditingContext Design Question
- Subject: Re: Practical EditingContext Design Question
- From: Chuck Hill <email@hidden>
- Date: Thu, 16 Feb 2006 08:18:31 -0800
On Feb 16, 2006, at 7:15 AM, email@hidden 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
_______________________________________________
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