On Nov 19, 2007 5:42 PM, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]> wrote: > > Hi, Lasitha! (By the way, where are you from?) Oh, the beautiful town of kandy, sri lanka :)
> I'm planning to release the sources until this weekend. Great, thanks! Will be looking forward to it. In the meantime, may i ask whether/how HiberTapestry solves the problem posed in this thread? To wit: hibernate will detect and commit changes to dirty objects even if we've realized mid way through the unit-of-work that it should be rejected. Earlier replies have suggested either intermediate objects or marking retrieved objects as read only[1]. The Spring OSIV filter/interceptor avoids this problem by turning off automatic session flushing and relying on service layers to explicitly commit (either manually or declaratively)[2]. I've run across a variation of this where the filter/interceptor/decorator always rolled back the active transaction at the end of the request cycle. Service layers are again responsible for committing desirable changes and a commit immediately begins a new transaction on the same session (checkpointing?), so the rollback is a no-op on most requests. I suppose another option is to 'tell' the framework that we don't want to commit by throwing an exception (ugh!). Looking forward to your and other folks' thoughts on this. > This is one of the best reasons to use open-source code: you don't need to > trust something you don't know how it works. :) > Absolutely! Gotta love it. Cheers, lasitha Notes: [1] http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Query.html#setReadOnly(boolean) [2] http://static.springframework.org/spring/docs/2.0.x/api/index.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
