My goal is not to re-write the n-th transaction interceptor-wrapper. Rather, my first focus is consistent tapestry integration. And treating hibernate sessions the way you used to treat your db-connections is asking for trouble.
The key point with hibernate is, that the session and the objects loaded within the same are associated. Thus their lifetimes should be synchronised, they should live in the same context. That means choosing you hibernate session patter has implications how you want tapestry to handle you persistent properties and asos. Luckily, Tapestry is very nicely configurable in this respect. It also means that the service/dao layer is usually the wrong place for transaction/session demarcation, precisely because the persistent domain objects you get back from your service/dao usually (if you use proxys and lazy collections, which you should/must) refer to the session. You'll eventually end up tweaking your service-methods to preload certain lazy collections which you need to show on certain views and this is evil. So, bottom-line: We will have session-per-request, but it will be more then an interceptor. It'll be Datasqueezer, PropertyPersistenceStrategy and, possibly, ASO-Scope. btw.: We're about to move the project to javaforge, give it a cooler name and add all kinds of good stuff from Jesse's toolbox (integration for remoting, jms, drools, and more). > -----Original Message----- > From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 4:49 PM > To: Tapestry users > Subject: RE: Kickstart 0.2 released > > > Session per request is the simplest > and most efficient approach in many cases and it does not > require Java 5. Please look at the barebone implementation > with CGLib alone: > > http://sandbox.sourcelabs.com/kosta/hibernate-bhw/java/com/sou > rcelabs/hibernate/bhw/haop/doc/haop.html > There are links to a similar implementation with Spring. > HiveMind based implementation of the concept is very simple too. > > > > > > > Schulte Marcus <[EMAIL PROTECTED]> wrote: hi ted, > thanks for the feedback! > > > Why do you not use Hivetranse for session/transaction management? > > There has already been done alot of work on that. It is a clean > > Hivemind contribution. Check it out! > > http://hivetranse.sourceforge.net/ > > > That's a story which went a bit "unlucky". Last summer, I had > a look at > hivetranse, but it didn't support hivemind 1.1 yet which I > already used, and > I really didn't want to backport ;). Then, I'm quite fond of the > session-per-conversation pattern which is still not supported > by hivetranse. > It seems to be scheduled for hivetranse 0.6, however. Lastly, > I didn't have > the time to dig into hivetranse deeply enough to add what I needed. > > > Also, as you are using Java 5.0, I think you should > consider using the > > following patterns for generic data access objects: > > http://www.hibernate.org/328.html > > > That would mean a generic AbstractPersistenceService, ... > yes, looks like it > would make sense... > > > Another thing is the HibernateSqueezer on the wiki. I think it is > > really a good thing, and easy to implement thanks to Hivemind. > > http://wiki.apache.org/jakarta-tapestry/HibernateTapestrySquee > zer?highlight=%28hibernate%29 > > That's definitively on my list for the next release. I'd like to have > session-per-request, no detached objects as the second > supported pattern > (besides session-per-conversation). As far as i can see, > that'll need a > Datasqueezer and a custom PropertyPersistenceStrategy I'll take the > Wiki-thing as a starting point. Also, Jesse uses this > approach while I do > not (currently), so I hope I'll be able to take a lot from his code. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
