Check out this page with the Hivemind Utilities. It can help you set up the services you need to inject a DAO Service in any page and automating to the maximum the session and transaction management if you wish to.
http://hivetranse.sourceforge.net/web/index.html (check the HiveTranse utility) Regards, On 4/12/06, James Carman <[EMAIL PROTECTED]> wrote: > > 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] > > -- Pedro Viegas
