Anything which really wants to update the persistent objects should go on inside a service method. Then you can put the transaction interceptor on it.
-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reynolds Sent: Wednesday, April 12, 2006 6:01 PM To: tapestry-user@jakarta.apache.org Subject: Re: tapestry-hibernate integration problem So how does transaction demarcation work in this common tapestry sequence: 1) in pageBeginRender(), call a service method to load the persisted object and set it as a simple page property 2) tapestry form fields components then update the properties of the persisted object and call some validators 3) in the form submit listener method, do some additional cross-field validation 4) still within form submit, if validation does not succeed, rollback, set a message on the delegate and return null to stay on the same page OR 5) if validation succeeds, commit the transaction and return a link to the next page to force a redirect-after-post In this sequence I don't have a single service method which demarcates the transaction. I considered using a copy of the persisted object for manipulation within the page and them passing that into a service method for persisting the changes, but that adds a lot more code and even then I end up with 2 transactions, one for the object load (database select) and another for persisting the changes (database update). What am I missing? -- Mark R James Carman wrote: > In case you didn't notice, I use the Spring classes too. I just don't use > the Spring DI container. I use HiveMind. I do the same sort of transaction > demarcation (in fact, I use Spring's syntax, hehe). I just do it within my > hivemodule.xml file. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam > Gendler > Sent: Wednesday, April 12, 2006 11:26 AM > To: Tapestry users > Subject: Re: tapestry-hibernate integration problem > > I use the standard OpenSessionInView filter, which keep s a session > open throughout the processing of a single request. As for > transaction semantics, those are kept entirely in the service layer. > The UI layer is completely oblivious to transaction semantiks > precisely to avoid the problem you are having. My UI layer can call > service layer methods in full confidence that transaction semantics > will be correct. > > I use spring to define transactions around my service layer methods. > It uses AOP to ensure that a transaction already exists or is > created,m as appropriate, and that the transaction gets committed > wherever appropriate. Those rules are defined within the Spring > applicationContext.xml config file, so it is easy to change and keep > track of how each method is executing. > > My DAO layer is oblivious to what kind of transaction is currently > open, so that I don't have to redefine the same functionality for use > within different typs of transaction. > > The beauty of this system is that there is no code dealing with > transactions anywhere within my codebase. It all happens inside > spring, and the only reference to it is in a config file, rather than > having to make sure that transactions are started and committed in > attach/detahc methods al over my codebase, etc. > > --sam > > > On 4/12/06, James Carman <[EMAIL PROTECTED]> wrote: >> I wouldn't inject sessions into your pages directly. Dealing with the >> persistence store should be abstracted away from the view layer using a >> DAO/Repository layer. >> >> If you want an example of how to do that, you can download my example >> application (via SVN of course) from: >> >> http://www.carmanconsulting.com/svn/public/tapernate-example/trunk >> >> This example does include the Open-Session-In-View pattern along with a >> custom property persistence strategy for persistent entities and a few > other >> goodies. The source code for the other libraries can be obtained from: >> >> http://www.carmanconsulting.com/svn/public/tapernate/trunk >> http://svn.javaforge.com/svn/hivemind/spring-hibernate3/trunk >> http://svn.javaforge.com/svn/hivemind/hivemind-utils/trunk >> http://svn.javaforge.com/svn/hivemind/spring-transaction/trunk >> >> Note: To checkout from javaforge, you have to use anonymous/anon as the >> username/password. >> >> >> >> -----Original Message----- >> From: bėgantis debesis [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, April 12, 2006 8:21 AM >> To: tapestry-user@jakarta.apache.org >> Subject: tapestry-hibernate integration problem >> >> 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 >> >> >> >> --------------------------------------------------------------------- >> 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]
