Hi Fabrizio,
Beware, as this post is a rather lengthy one :-)
I'm trying to be a bit more brief this time :-)
I've read up a bit on the Hibernate docs / forums, and wow that stuff is
much more detailed now than when I last checked (can't remember when
that was though).
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. 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.
- 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. (Many people would maybe show a "deletion
successful" message first). This does usually not work unless you flush
the deletion before rendering the view. 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.
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.
(BTW, It's really a shame that the InheritableThreadLocal thingy, which
also originated here on the list more than a year ago, has not even made
it to wiki yet. Blame me for it.)
Regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
