If you use the OpenSessionInViewFilter, this problem goes away, as only one session is used for the entire request cycle.
The transaction interceptor doesn't just begin/commit transactions. It also allows you to declare which exceptions would need to cause a rollback (and which do not). Using the transaction-per-request paradigm and the transaction interceptor are not (as you pointed out in another email) mutually exclusive. If I was going to do transaction-per-request, I'd implement it as a filter (much like the OpenSessionInViewFilter), though. That way, my pages wouldn't have to worry about manually managing their transactions. If declarative ta-demarcation isn't necessary for your application, you can still use the HiveMind/Spring integration classes to write your TransactionPerRequestFilter. That way, all you're using is the PlatformTransactionManager to begin/commit/rollback your transaction. You would, however, have to manually set (or write use the transaction interceptor for this) the rollback only flag if you want to make sure that the transaction is rolled back. I would have to say that your 99% estimate is a bit high. I would agree that transaction-per-request would work for a high percentage, but not quite 99%. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 6:19 AM To: 'Tapestry users' Subject: RE: [Honeycomb] net.sourceforge.hivetranse.transaction.MandatoryT ransactionException ah, now your seem to be running into the problem Mark Reynolds described in another thread. Now, you're calling a service-method (with ta required) to load you object, first hibernate session, return - session closed. Then your squeezer is called, second session, you pass it a hibernate proxy from another session - and WHAM. And: it's completely pointless to have multiple hibernate session per request (unless you have a very good reason and know what you do). So, you should really declare all your methods "mandatory" (sorry, I was wrong before). Then of course you'll have to start/commit your ta's above the service layer. And your cool ta-interceptor does nothing but check for the presence of a ta. Hey, why o why do you guys use think the declarative ta-stuff is useful for your apps? Do you reuse your dao's/services so heavily in completely different contexts? yes, yes, of course you can make it work. And it looks sooo enterprisy. But it's really just making something really simple, really complicated 99% of the time. Oh, sorry, now I'm really gettin into a rant, but I just don't get it And while I'm at it: - A hibernate entity IS NO POJO. Your class may be a POJC, but always assume that the object is some bytecode-enhanced proxy with access to the session it was loaded in. - A hibernate session is no db-connection, nor is it a db-transaction, it (usually) needs/has one. It's more of an in-memory representation of a subset (hopefully) of your db-entities. They *might* have been loaded in one DB-Transaction but they needn't be. > -----Original Message----- > From: Andreas Bulling [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 11:50 AM > To: Tapestry users > Subject: Re: [Honeycomb] > net.sourceforge.hivetranse.transaction.MandatoryT ransactionException > > > On 24. Apr 2006 - 09:10:32, Schulte Marcus wrote: > | It seems that hivetranse implicitly marks the hibernate > session methods > | "mandatory", assuming that eache service using it uses at > least "requires". > | Which is basically sound. you might try to mark your > HibernateSqueezer's > | squeeze method with ta-required (however you do this in hivetranse). > > Thanks for your answer! > I tried the following: > > <service-point id="HibernateSqueezer" > interface="org.apache.tapestry.util.io.SqueezeAdaptor"> > <invoke-factory> > <construct class="HibernateSqueezer"/> > </invoke-factory> > <interceptor > service-id="hivetranse.core.TransactionInterceptor"> > <method pattern="squeeze" demarcation="Required"/> > <method pattern="unsqueeze" demarcation="Required"/> > </interceptor> > </service-point> > > But now I get the following exception: > > org.hibernate.TransientObjectException > proxy was not associated with the session > messages: > > * proxy was not associated with the session > > throwableCount: 1 > throwables: > > * org.hibernate.TransientObjectException: proxy was not > associated with the session > > Stack Trace: > > * > org.hibernate.impl.SessionImpl.getEntityName(SessionImpl.java:1701) > * sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > * > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.java:39) > * > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessorImpl.java:25) > * java.lang.reflect.Method.invoke(Method.java:585) > * > net.sourceforge.hivetranse.transaction.hibernate3.SessionProxy > Factory$SessionProxy.invoke(SessionProxyFactory.java:213) > * $Proxy33.getEntityName(Unknown Source) > * $Session_10acb48386b.getEntityName($Session_10acb48386b.java) > * $Session_10acb483705.getEntityName($Session_10acb483705.java) > * > de.plattform.services.HibernateSqueezer.squeeze(HibernateSquee > zer.java:50) > * sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > * > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > orImpl.java:39) > * > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > odAccessorImpl.java:25) > * java.lang.reflect.Method.invoke(Method.java:585) > * > net.sourceforge.hivetranse.transaction.TransactionInterceptorF > actory$Interceptor.invoke(TransactionInterceptorFactory.java:125) > * $Proxy36.squeeze(Unknown Source) > * > $SqueezeAdaptor_10acb483871.squeeze($SqueezeAdaptor_10acb483871.java) > * > org.apache.tapestry.util.io.DataSqueezerImpl.squeeze(DataSquee > zerImpl.java:127) > * > $DataSqueezer_10acb4836ff.squeeze($DataSqueezer_10acb4836ff.java) > * > org.apache.tapestry.form.Hidden.renderFormComponent(Hidden.java:58) > > > --------------------------------------------------------------------- > 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]
