More on Cayenne usage patterns...
My current customer project has this pattern (somewhat similar to
what Tore has described) - a CMS used by a limited number of people
to edit content and an extremely high-volume site that serves this
content (fwiw, Tapestry 4 is used as a web framework). Here is a few
random notes from this experience:
* The more complexity and/or load you have in your apps, the bigger
chance that any generic solution will not work 100% and will have to
be tweaked to address a specific use pattern.
* If a read-only application doesn't have any user state, make it
session-less. In fact a single DataContext shared across multiple
sessions (application DataContext) can be used without explicit
synchronization, as select/refresh operations are synchronized by
Cayenne already. This increases throughput tremendously.
* If there is some user-specific state, but most data is stateless,
use two contexts - application and session.
* Per-request DataContext can be used if the data changes frequently.
However switching to Cayenne 3.0 can eliminate the need for this, as
data refresh policies become mostly declarative:
- Tag your queries with "cache group" strings
- Data changes that follow a certain pattern can be configured by
using OSCache expiration and cron policies set by cache group.
- "Random" user initiated data changes can be synchronized using
OSCache JavaGroups mechanism and entity callbacks. Unlike Cayenne
snapshot events, these events will invalidate query lists, and can be
made very precise (only relevant changes will generate events).
* [I haven't tried this one yet] Read/write applications should
probably use a synchronized session DataContext. I guess the scope of
request lock can be reduced by only creating the lock when the
session context is requested for the first time (or when the first
object becomes dirty?), so that read-only requests can still go through.
Again - see item 1 - this works for certain applications and may not
work for certain other applications.
Andrus
On Oct 12, 2006, at 3:31 AM, Tore Halset wrote:
> Hello.
>
> Sorry for bringing up this old issue..
>
> I have read this thread and talked to Øyvind Harboe about it.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-cayenne-user/
> 200609.mbox/%
> 3cc09652430609290646j2a84697v1216d35667ffc9c..ail.gmail.com%3e>
>
> and Mike Kienenbergers solution.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-cayenne-user/
> 200609.mbox/%
> 3c8f985b960609291128m529a63e4ra7e7de71b7353cc..ail.gmail.com%3e>
>
> I am binding DataContext to a session via tapestry-3 Visit. This
> has not been a problem in my application. Probably as most of the
> heavy cayenne use are done via a swing client that does not make
> parallell requests. The web-guis that are using tapestry+cayenne
> are mostly read only. The read/write stuff are mostly for internal
> administration.
>
> So I see the following two possible situations:
> * One Context per session: Must make sure only one thread are
> using the same session at a time. F.eks. by using Mike
> Kienenbergers filter that synchronizes on the session-object.
> * One Context per thread: Thread safe, but will have to move
> objects between Contexts for objects that live longer than a single
> request. Can this be done sort of automatically?
>
> - Tore.
This archive was generated by hypermail 2.0.0 : Thu Oct 12 2006 - 10:47:41 EDT