cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabrizio Sitzia" <>
Subject Re: CForms/Flowscript and Hibernate long sessions
Date Thu, 24 May 2007 07:47:56 GMT
Hi Johannes,

I'm trying to be a bit more brief as well, this time ;-)

> ...
> I think I have to admit that it would indeed not be a very good idea to
> let the DAOs handle session demarcation themselves. I think the approach
> as presented in wiki more or less matches the "one session per request"
> pattern of the Hibernate docs. Actually, the setup I am using in my
> current projects is more or less equivalent to the one you described,
> except that I'm not using "long sessions", but then, even the Hibernate
> docs tell us that there is room for both (long and "short"
> conversations) in this universe.
> As far as I understand it by now, if you wish to do "long conversations"
> with Hibernate and Cocoon, there might be no convincing alternative to
> session / transaction demarcation on the flow script level, since this
> is the only place where you can conveniently store information across a
> long session. It is still my gut feeling that it simply does not belong
> there, though.

I agree. Intermixing Hibernate session / transaction demarcation code
with flowscript smells!
But then, transaction demarcation is awkward to implement in just one
specific layer (DAO, Flowscript, servlet filter...)

It is one of those 'cross-cutting concerns' that would perhaps be best
addressed by an AOP framework - that's why I briefly considered Spring.
(But I dismissed it as it would involve a complete application

> So, the alternative approach which I would propose, is
> using the "one session per request" pattern, but with Hibernate out of
> the scope of the flow script layer.  Or, coming back to your
> deleteAllIcons() example:
> - At the beginning of the request, a Hibernate session is opened and a
> transaction is started by the servlet filter. (As opposed to my current
> setup, where the session is still opened in flowscript). The session is
> stored in an InheritableThreadLocal.

Would you still be getting a JDBC connection from Cocoon's db connection
pools? (How would you manage to do that out of a servlet filter?)

> - In flowscript, the method "getAllIcons()" is called on the IconDAO.
> - showForm is called, the view rendered.
> - Transaction and session are closed by the servlet filter.
> - Upon submitting the form, a new session is opened and a new
> transaction started.
> - Icons are deleted as usual, but since this happens inside a
> transaction, it's "all or nothing".
> My only concern with this approach is that you might sometimes need a
> more granular transaction demarcation. For example, when you delete an
> object, and then want to directly render the list of objects again,
> excluding the deleted object.

I ran into that problem myself when I started modifying tree-like
data structures that were subsequently rendered in the view.

> (Many people would maybe show a "deletion
> successful" message first). This does usually not work unless you flush
> the deletion before rendering the view.

That was also my solution! Flush, then refresh the tree before
rendering the view ...not elegant, but very pragmatic ;-)

> Again, I would create a Java
> helper object which allows me to flush the current transaction and start
> a new one, instead of explicitly working with the Hibernate methods in
> my flowscript.
> I guess both approaches are valid, just as the Hibernate docs mention
> both the "one session per request" and the "long conversation" patterns.
> Whether you want to use Hibernate directly in flowscript or rather hide
> it away in Java helper classes does not really make any difference to
> the pattern itself.

Hiding it away in Java helper classes is definitely cleaner!

> So far, this was a really interesting thread. I think we should really
> try to digest this into an update of the wiki tutorial, maybe describing
> both approaches on separate pages, WDYT? Maybe you could create a new
> article, "Cocoon, Hibernate and the long conversation pattern" or
> something similar, and I will try my best to update the sample
> application in the way I described. The original tutorial is already
> quite long, so that this is maybe also the time to split it onto several
> pages...

Good idea :-)

As time permits, I'm going to prepare a tutorial describing the long
conversation pattern and its current implementation, which is based
on the concepts and the code which you provided in your Wiki tutorial.

And I think the sample application you have described above could easily be
extended to handle the long conversation pattern as well. The Java helper
object would be a more proper place for the various transaction demarcation
methods required for implementing a long session.
There's already quite a bit of potential for 'session-per-request & long
conversation patterns revisited' Wiki tutorials :->

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message