James, of course ta-per-request and declarative ta-demarcation are not mutually exclusive and I certainly did not claim that. What I did claim is, that having to set up a client ta-context in a separate "filter" (be it a servlet filter or a DirectService override or sth. along these lines) pretty much renders the declarative stuff pointless imo. It complicates the machinery with no significant gain I can see. When, effectively, all your methods should have "mandatory", what you have is a fancy kind of debug-assertion.
And even if ta-per-request doesn't work in more cases than the rather rhetorical 1%: In those cases, I doubt, however, that declarative ta-demarcation would be of any help. The use cases for declarative ta-demarcation of a service component imo are - deploying the component in unknown transaction contexts (the classical EJB-vendor stuff) - freeing the components developer of the need to handle ta's her/himself - provided he would have to do that otherwise. > -----Original Message----- > From: James Carman [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 1:48 PM > To: 'Tapestry users' > Subject: RE: [Honeycomb] > net.sourceforge.hivetranse.transaction.MandatoryT ransactionException > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
