cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: context - in thread or session?
Date Thu, 12 Oct 2006 14:47:02 GMT
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/% 
> 3cc09652430609290646j2a84697v1216d35667ffc9ce@mail.gmail.com%3e>
>
> and Mike Kienenbergers solution.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-cayenne-user/ 
> 200609.mbox/% 
> 3c8f985b960609291128m529a63e4ra7e7de71b7353cce@mail.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.


Mime
View raw message