As usual it depends: you are correct that often H persisted objects do need session due to "lazy" settings, however I would say that heavy reliance on "lazy" loading does not seem very reliable and convenient for me, and might not benefit performance and convenience. IMO manging transactions at business logic tier is quite nice approach: for example it allows using the business layer via various RPC like SOAP, Hessian, RMI, etc. without any changes anywhere. Having transaction management confined in the business layer makes testing a breeze. It looks like "lazy" loading mostly used to achieve acceptable performance for list queries, when HQL asks for heavy objects and H brings back just bare bone proxies. It is more beneficial to use straight SQL via H or iBatis http://sandbox.sourcelabs.com/kosta/hb-beyond-hw/java/com/sourcelabs/hibernate/bhw/hplusibatis/doc/hplusibatis.html to query for brief information about objects and allow user to decide what object to manage, and only then load fully instantiated object. I suggest minimizing use of "lazy" loading.
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 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] Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
