Hi Andrus,
I believe I found a correct balance in using the OC between Session,
Request and Application. As soon as I am done with writing the Demo
app for the new JPublish-Cayenne integration I'll also start stress
testing it and let you guys know how it goes. If I could only learn
faster the Cayenne query language :)
For example, my implementation will detect if the HttpRequest is for
an url where the Session is enabled; with JPublish one can specify
the url paths where the Session will be disabled. If there is a
Session then it will be used and the OC will follow the Session life
cycle.
If the Session is not enabled at all or the request is for an url
where the application or the programmer explicitly denies the session
creation, the OC will be created in the local thread for the Request
and passed through towards the following chained Actions and
ViewRenderer. At the end of the request, I have an "after" advice-
like Action which is just setting the OC to null:
DataContext.bindThreadDataContext(null); // using Cayenne 2.x's DC
for now, OC next
but before that is checking if there is a need for auto rolling back.
For R/O calls (as illustrated in the xml below) a global OC (per
Application) is used. This global instance is initiated when JPublish
starts and is cleaned at shutdown or on Servlet destroy event,
nothing new here.
What's nice about this is that in the same Action/Velocity/Freemarker
code, one can mix R/W with R/O Cayenne calls and I have very good
results so far :)
Most probably I will commit the code this week and I will let you
guys know in case you are curious to see how it's working, if you
don't mind.
Thanks for support guys,
-florin
On 26-Sep-07, at 04:24 , Andrus Adamchik wrote:
Hi Florin,
Thank you for reply. Following your advice and Malcolm's -the
author of the CLICK web framework-, I (almost :) got a prototype
working.
Nice.
Though I am not sure I have to do anything for the OC, after a
request was executed?!
Probably nothing. Some people who use a session context and never
care to preserve the state between requests, may want to rollback
(or commit?) the session context at the end of the cycle. Not sure
how widespread such pattern is.
Andrus
On Sep 23, 2007, at 9:38 PM, Florin T.PATRASCU wrote:
Hi Andrus,
Thank you for reply. Following your advice and Malcolm's -the
author of the CLICK web framework-, I (almost :) got a prototype
working.
I am configuring my module like this:
<!--JPublish Cayenne support -->
<module classname="org.jpublish.module.cayenne.JPCayenneModule">
<cayenne-config-path>/WEB-INF/cayenne</cayenne-config-path>
<auto-rollback>true</auto-rollback>
<session-scope>false</session-scope>
<shared-cache>true</shared-cache>
<!--
~ Http request paths using a per-request or a per-session
Cayenne ObjectContext (OC),
~ the read-only paths will be interpreted first and will
use a global OC one defined
~ per web app instance.
~ -->
<cayenne-enabled-urls>
<url path="/info/*" readonly="true"/>
<url path="/status/*" readonly="true"/>
<url path="/rss/*" readonly="true"/>
<url path="/users/*" readonly="false"/>
<url path="/companies/*"/> <!--readonly="false" by
default, if not defined-->
</cayenne-enabled-urls>
<debug>true</debug>
</module>
, where the module executes Before and After Actions for a request
following the request path rules above. Though I am not sure I
have to do anything for the OC, after a request was executed?!
And since I am not using a Filter nor an additional Servlet (so
the user can control the Cayenne behavior from the JPublish
configuration file only), I can disable/enable the use/creation of
the HttpSession, and when the session is disabled an "OC per
request" will be created, otherwise I'll use the HttpSession as
some of the web frameworks I was looking at are already doing it.
For the read-only requests I will use an "OC per app" as you
recommended.
Even though I am very new to Cayenne I can say already that I like
Cayenne :)
Many thanks for support,
-florin
On 23-Sep-07, at 13:41 , Andrus Adamchik wrote:
I generally use a new DataContext per thread, with a Filter
binding the DataContext to request thread.
I think at some point we should update the docs for 3.0 with
information discussing 3 main patterns with all drawbacks and
benefits. Here is a short summary:
* OC per request
- no synchronization issues, smallest memory footprint
- some overhead in creating a new DataContext on every request
- no "local" caching (can be good or bad depending on the app)
- no uncommitted state is allowed between requests
* OC per session:
- Potential synchronization issues on update (if the same user
clicks too fast). Possible solution - nested DataContexts per
request working off of a single session context. Another
solution is synchronization of action methods.
- efficient local cache
- uncommitted state can be preserved between requests
OC per app
- applicable for read-only applications (no special
synchronization required in this case)
- very efficient local cache
Andrus
On Sep 23, 2007, at 2:09 PM, Malcolm Edgar wrote:
Hi Florin,
I generally use a new DataContext per thread, with a Filter
binding the DataContext to request thread. Please see the
attached example.
regards Malcolm Edgar
http://click.sourceforge.net
On 9/23/07, Florin T.PATRASCU <[EMAIL PROTECTED]> wrote:
Hi there,
I am trying to add Cayenne support to the JPublish web framework
( http://code.google.com/p/jpublish/) and being very new to
Cayenne I
would like, if possible, to find which is the best practice for
obtaining and using the OC?
I browsed the threads here and most of the information I have show
that one of the most common solution is to use the HttpSession.
That's clear and I can do that very easy, but I wonder if there
is a
better way because I would like to use Cayenne for session-less
requests as well. So, would it be prohibitive to create an OC for
every HttpRequest? aka:
ObjectContext oc = DataContext.createDataContext();
If not, would this pattern affect the server stability (memory,
handlers, threads, db pools, etc.)? What about having a global OC
instance per application?
Also, is it safe to start developing on top of the Cayenne 3.x
version?
Being my first post on this forum, I would like to thank Cayenne's
creators for making it available and to you, the users, for the
useful information accumulated in this forum during the time.
Thank you,
-florin