Hi Mark, That's right, hivetranse was targeted to HiveMind in general (and not to Tapestry; for one good reason at least: I never used Tapestry!). Originally, the idea was to support Hibernate, but the idea has grown a bit to support transactions in general (like in spring or EJB), and potentially support other persistence layers (like iBATIS).
That means that, unfortunately, I am not the person to recommend best practices on using HiveTranse within Tapestry applications (but I hope that people who have done this already can help you on this point). However, what I can do, of course, is to improve hivetranse (without linking it to tapestry, although) according to remarks or problems that Tapestry users have in particular, according to what I understand of a specific problem, I can come up with a solution that would work around the problem. This is what I suggested for the initial problem mentioned at the beginning of this thread, I think that now I understant better the problem, and I can try to work out a solution for it. Cheers Jean-Francois -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reynolds Sent: Friday, April 14, 2006 7:38 AM To: tapestry-user@jakarta.apache.org Subject: Re: Open Session in View - Tapestry Jean-Francois, I certainly did not mean to imply this is a bug or any deficiency of hivetranse. I find hivetranse quite solid. :) I believe that it wasn't primarily designed for a Tapestry application or tailored exclusively for Hiberate. So for me, it is a question of how should it (or can it) be properly applied to a Tapestry application? I did try the approach you suggest, but it really is not very natural to make it work with Tapestry's form/object updating and validation, unless you create separate domain objects for the web layer and persistence and copy from one to another, which I would like to avoid. At least that was the best I could come up with... Thanks! -- Mark R Jean-Francois Poilpret wrote: > Hello Mark, > > This "problem" is by design (for me it is not a bug, this is the way > transaction demarcation is supposed to work in hivetranse, changing it would > bring compatibility problems with existing applications, however, this could > probably be done through some extra setting, I will think about it, but I > need to check if there is no ambiguous cases with that). > > For the time being, what is possible (and that I consider clean, although > some people in this list have shown some disagreement to this approach) is > to put the transaction demarcation "Required" at a method in a façade, this > method can then call different methods of other services or DAO, all in the > same transaction. > > Hope this provides a little help;-) > > Cheers > > Jean-Francois > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reynolds > Sent: Thursday, April 13, 2006 4:42 AM > To: tapestry-user@jakarta.apache.org > Subject: Re: Open Session in View - Tapestry > > I tried the hivetranse approach, but had 2 problems. 1) hivetranse seems > to limit a hibernate session to a single transaction, and 2) its > declarative approach ultimately limits the transaction demarcation to a > single method call, and I couldn't figure out a good way to structure my > application such that all the work (load object, update object, commit > transaction) occurred within the scope of a single service method call > and still left me with a place to catch any exception and update the > view accordingly. > > If someone has worked out a good pattern for using hivetranse in the > context of simple hibernate-based CRUD functionality in Tapestry 4 with > validation, I would love to hear about it. > > I also looked at what Howard is doing with Epluribus > (http://www.javaforge.com/proj/sources/sccBrowse.do?proj_id=220&dir=epluribu > s%2Ftrunk), > but that is unfinished (it does have an example of a > WebRequestServicerFilter, which is what you need to make sure the > transaction is committed/rolled-back at the end of the request, as > stated in your question). > > I ended up adapting Kent Tong's SessionOwner approach from Chapter 14 of > his indispensable book. It involves injecting the thread-specific > SessionOwner (I called it TransactionManager) into your page and using > it to commit or rollback the transction as desired. > > -- Mark R > > Sukma Agung Verdianto wrote: >> Hi, >> >> I'm trying to implement Open Session in View in tapestry application. >> There is a way to create servlet filter to open and close the db session. >> (I'm using ServletRequestServicer) >> My question is, how can I catch the page exception to rollback the >> transaction, because >> tapestry ExceptionHandling catch that exceptin and never throw it as > servlet >> exception. >> Sorry for my bad english :( >> >> Rdgs, >> Verdianto >> > > > --------------------------------------------------------------------- > 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]
