You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Tore Halset <ha...@pvv.ntnu.no> on 2006/10/12 09:31:05 UTC
context - in thread or session?
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.
Re: context - in thread or session?
Posted by Øyvind Harboe <oy...@zylin.com>.
What scares me about this is that it *appears* to work just fine when
putting a DataContext in a Tapestry Visit object.
Tapestry promises to run all Page objects on a single thread, but what
is far from obvious is that access to the Visit object is not
similarly single threaded.
Is it (in theory) possible for a DataContext to throw an exception if
misused in this way?
--
Øyvind Harboe
http://www.zylin.com
Re: context - in thread or session?
Posted by Tore Halset <ha...@pvv.ntnu.no>.
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/%
>> 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.
>
Re: context - in thread or session?
Posted by Andrus Adamchik <an...@objectstyle.org>.
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.