On Nov 19, 2007 5:42 PM, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]> wrote: > On Mon, 19 Nov 2007 07:17:32 -0200, lasitha <[EMAIL PROTECTED]> > wrote: > > [.... a long descpription on the 'unintended save' problem ...] > > > On Oct 31, 2007, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]> wrote: > > > > Thiago, any chance you'll be releasing the source [of HiberTapestry] soon? > > I'm planning to release the sources until this weekend.
Thiago, thanks for releasing that, i've finally had some time to look into it this weekend. Looks neat - well done :). Some thoughts relevant to the 'unintended save' problem: * I think HiberTapestry mostly solves it. * The only hole i can see is that even though we only commit explicitly at the successful completion of a @Transactional method, i think it's possible that hibernate will automatically flush the session at unexpected moments. The default FlushMode.AUTO documentation specifies: "The Session is sometimes flushed before query execution in order to ensure that queries never return stale state". If this happens before we are ready, we may still be open to unintentional saves. Would it be safer to set the flush mode to COMMIT instead? More general feedback: * In our own solution to the problem (see below), we found it useful to be able to annotate page/component methods. In fact i think our most common case is to mark the onSuccess event as the commit point. Since tapestry-ioc doesn't decorate pages and components, we are contributing a ComponentClassTransformWorker that injects the transactional code into pages. This may be some neat functionality to add to HiberTapestry. * I'm not sure if https://issues.apache.org/jira/browse/TAPESTRY-1874 is still valid. I am able to get Match("*") to work without tapestry complaning about IOC services. Might be something to look into as it would elimante the naming convention limitation. Our homegrown solution so far: * We override and alias the HibernateSessionManager so that it always _rolls back_ on thread cleanup. * We set the flush mode to AUTO (also by overriding the HSM). * We introduce a @CommitOnCompletion annotation that tells the framework to call HSM.commit() when the marked method completes. This will commit the transaction that was begun when the session was first created, and begin a new one for the rest of the request cycle. If the method is never called or hits an exception everything is rolled back. If you see any problem with that solution, please let us know. In any case, i suspect this whole problem will be superceded by the (hopefully) upcoming support for 'conversations'. Be well, lasitha. P.S. I am leaving my current job (and considering a career change :), so i may not do a good job of following up on this thread. My apologies in advance. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
