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 re-design...) > 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, Fabrizio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
