Okay, so what you're saying is to throw it all away and go with a more simplistic framework (transaction-per-request only). But, what if somewhere down the road, you do actually need it (like if you want to log audit messages to the database when something goes wrong and your transaction has to be rolled back)? With the transaction interceptor, it's easy to add that in at a later time, if necessary. So, why not include it? Of course it's much easier to just wrap everything in one transaction (as I did in my HiveMind article). But, sometimes you need more fine-grained control over what's going on.
The folks who wrote Spring didn't just do the ta-demarcation stuff because the EJB folks did or because they were doing it just in case. There are real-world use cases for it and it does come in handy. I think we're arguing a moot point. If you want to use ta-demarcation, use it. If you don't, you don't have to (as long as you're using transaction-per-request of course). But, by including it, we're making it a more robust framework. I would agree that for the most part, I would use transaction-per-request. It does make things much simpler. But, there are those rare cases. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 9:52 AM To: 'Tapestry users' Subject: RE: [Honeycomb] net.sourceforge.hivetranse.transaction.MandatoryT ransactionException 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
