So, what do you suggest? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 13, 2006 10:59 AM To: 'Tapestry users' Subject: RE: tapestry-hibernate integration problem
You're right it's not a bug in the framework. I didn't mean to say this. What I meant to call "wrong" is, more precisely, the developers assumption that declarative ta-demarcation frees him (as the "gui-guy") from thinking about transactions, because the backend-guy would just declare what his methods need and that's it. And this assumption is not just the developers' fault. Indeed declarative TA is often advertised this way. The fact that hibernate objects passed through a session-facade usually carry technical state (regarding the hibernate-session) with them (detached, transient, attached) makes this assumption even more wrong. bottomline: A session facade as the ta-(and hibernate-session-management-) boundary is, imo, a bad design for most web-apps. Of course you can make it work, but it's tedious and error-prone. > -----Original Message----- > From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 4:25 PM > To: 'Tapestry users' > Subject: RE: tapestry-hibernate integration problem > > > Marcus, > > The problem you describe about a developer using spring/hibernate with > declarative ta demarcation is more a problem of training of > the developer > rather than a bug in the framework: if developers just > "assume" things about > a framework without even checking the doc (or building a > prototype if the > doc does not mention for it), then the fault is on the > developer (or the > organization to which he belongs) not on the framework, I believe. > > Cheers > > Jean-Francois > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 13, 2006 1:15 PM > To: 'Tapestry users' > Subject: RE: tapestry-hibernate integration problem > > I currently think that declarative ta-demarcation at the > service-facade in a > typical web-app with hibernate is just plain wrong. Because > it pretends to > hide something (the hibernate session and its lifecycle) > which it doesn't. > Example from a Spring/Hibernate project I was involved in > some time ago: a > developer called two service-methods, both marked as "requires ta" in > application.xml, in one http request. He thought, they would > run in the same > ta, which, of course, they didn't. This was a rather nasty bug. > Since then I have ta control in some point of the web-layer > (DirectService.trigger). This works very well for me. Of > course this is also > the approach taken in honeycomb. > > See also: > http://marcus-schulte.blogspot.com/2005/04/if-you-cant-hide-it > -below-hide-it > .html > > > -----Original Message----- > > From: Mark Reynolds [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 13, 2006 4:51 AM > > To: tapestry-user@jakarta.apache.org > > Subject: Re: tapestry-hibernate integration problem > > > > > > The problem I experienced using hivetranse and the "open session in > > view" was this: > > > > 1) execute one transactional method, transaction is committed > > when the > > method returns and the hibernate session is kept open > > 2) execute another transactional method, hivetranse opens a second > > hibernate session, transaction is committed when the method > > returns and > > the hibernate session is kept open > > > > Now I have two hibernate sessions for the same request and > can easily > > get hibernate errors regarding the same persistent object > > being on two > > different sessions. > > > > It seems like hivetranse should be able to reuse the same session > > throughout a single request, as long as it doesn't hit a > > nested method > > demarcated as "requires new". > > > > Has anyone found a solution for this? Or at least seen the > same issue? > > > > -- Mark R > > > > Nick Faiz wrote: > > > Just a note that you dont need to write code to control the > > Hibernate > > > session & transaction lifecycles if you use HiveUtils (aka > > Hivetranse). > > > > > > http://sourceforge.net/projects/hivetranse/ > > > > > > In my current project, I configured the hibernate session > > as a hivemind > > > component, which is injected into whichever component I > > like. I also use > > > the HiveUtils transaction interceptor, which > transparently handles > > > transactions for all components using it, following the > > 'open session in > > > view' pattern. > > > > > > > > http://hivetranse.sourceforge.net/web/quickstart.html#start.co > > nfig.hibernate > > > > > > > > > Nick > > > > > > On 12/04/2006, at 10:21 PM, begantis debesis wrote: > > > > > >> Hi everyone, > > >> > > >> I extended a BasePage and added there a getSession method, > > which opens a > > >> hibernate session and starts a transaction (if it is not > > yet opened). > > >> Also, > > >> I commit the transaction and close the session on the overrided > > >> BasePage.detach() method. > > >> > > >> The problem is that when I save something on page 1 and > > then redirect to > > >> page 2, page 2 gets the old information from the > database. That is > > >> because > > >> detach method on page1 (where the transaction commit > > resides) is invoked > > >> after page2 getInformation() method called. > > >> > > >> So, the question is, is there a method like detach but > > which is invoked > > >> before another page starts its activities? Or maybe using > > transaction per > > >> request is bad at all? > > >> > > >> Or maybe you know some other easy way to intergrate tapestry and > > >> hibernate? > > >> > > >> Thank you in advance, > > >> Valdemaras > > > > > > Nick Faiz, > > > Developer > > > www.q9software.com > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
