Thanks for this answer!
- Tore.
On Oct 12, 2006, at 16:47, Andrus Adamchik wrote:
> 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 : Sat Oct 14 2006 - 16:49:41 EDT