Nice!! Keep up the good work!
/ted On 1/18/06, Schulte Marcus <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
