not if you buffer the response like wicket does by default :) -igor
On Thu, Mar 26, 2009 at 2:34 PM, Maarten Bosteels <mbosteels....@gmail.com> wrote: > Igor, > > IIUC, transaction-per-request will commit AFTER the response has been > rendered, right ? > That means that there's also risk for inconsistency: when the commit > fails, user will think everything is fine, but changes are rolled > back. > Or am I missing something ? > > Maarten > > On Thu, Mar 26, 2009 at 7:30 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: >> there are three patterns to transaction management >> >> the default pattern is session-per-transaction. this is not convenient >> because after your business logic closes the transaction you can no >> longer use the session in the ui. >> >> there are two ways to solve this: either use session-per-request - >> which means on first transaction you open a session, and keep it open >> for the duration of the requests. transactions share the session and >> even after the transactions are done you still have a session. this is >> better because after your business logic is done you have the session >> you can use for ui with all the stuff from business logic already >> loaded. this is what the spring osiv filter does. >> >> the other way is a single transaction-per-request. this means on first >> access you create a session and a transaction. all other operations >> inside a request run within that one transaction. >> >> the difference between session-per-request and transaction-per-request >> is data integrity from the user's perspective. if the user sees an >> error page have his changes been saved to the database to some degree? >> with transaction-per-request you are guaranteed that if user sees an >> error screen none of their changes have been preserved - because >> whatever displayed the error screen also rolled back the transaction. >> with session-per-request there is no such guarantee. eg the business >> logic runs fine and saves the data but an error in the ui causes an >> error page. user sees an error - but the data is already saved - a >> little inconsistent. >> >> personally i prefer transaction-per-request but afaik there is nothing >> baked into spring that will do that so you will have to roll your own. >> >> -igor >> >> On Thu, Mar 26, 2009 at 5:31 AM, Kaspar Fischer <fisch...@inf.ethz.ch> wrote: >>> I am learning about the OSIV pattern and have so far read the introduction >>> at hibernate.org [1], the Spring JavaDoc for OpenSessionInViewFilter [2], >>> the excellent MysticCoders tutorial [3] that uses Spring's >>> OpenSessionInViewFilter, and some more. >>> >>> I have basic questions: >>> >>> 1. Is it correct that there are two variants of the pattern? >>> >>> In one variant there is a single transaction (and a single session) that >>> gets committed at the end of the request, as described in [1]. If I am not >>> mistaken, James's wicket-advanced application [5] also uses this variant. >>> >>> In the second variant, there is an intermediate commit. We therefore have >>> two transactions (and one or two Hibernate sessions). Examples for this are >>> WicketRAD and the London-Wicket PDF [4]. >>> >>> 2. The first variant has the disadvantage that the code handling the request >>> cannot handle errors itself as the commit takes place at the end of the >>> request, in a filter. Correct? >>> >>> As a concrete example, this means that if my code inserts an item that >>> already exists and does not explicitly check for duplicates, the request >>> will result in a rollback and the default error page. Where I would have >>> preferred to see a feedback message "This item already exists". (It seems to >>> me, however, that it is not a good practice to move error checking concerns >>> to the database integrity layer, so the code *should* check for >>> duplicates...) >>> >>> 4. Which variant(s) doe Spring's OpenSessionInViewFilter support and how >>> does it work? >>> >>> I do not fully understand the documentation of the class but have the >>> feeling it implements the second, and you can specify whether you want a >>> single or two Hibernate sessions. I read [3]: >>> >>> "NOTE: This filter will by default not flush the Hibernate Session, with the >>> flush mode set to FlushMode.NEVER. It assumes to be used in combination with >>> service layer transactions that care for the flushing: The active >>> transaction manager will temporarily change the flush mode to FlushMode.AUTO >>> during a read-write transaction, with the flush mode reset toFlushMode.NEVER >>> at the end of each transaction. If you intend to use this filter without >>> transactions, consider changing the default flush mode (through the >>> "flushMode" property)." >>> >>> Here is my understanding of this, assuming I have configured a Spring >>> transaction manager and use transaction annotations: >>> >>> When a request starts, a Hibernate session is opened. When the first method >>> with a @Transactional annotation is encountered, a transaction is started, >>> and Hibernate's session is associated with this transaction. When the method >>> exits, the transaction is committed but the session is left open (the OSIV >>> behaviour). At the end of the request, the session is closed. Is this >>> correct? >>> >>> Thanks for a reply and sorry for the lengthy post, >>> Kaspar >>> >>> -- >>> [1] http://www.hibernate.org/43.html >>> [2] >>> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html >>> [3] >>> http://www.mysticcoders.com/blog/2009/03/13/5-days-of-wicket-putting-it-all-together/ >>> [4] >>> http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-OpenSessionInView.pdf&can=2&q= >>> [5] http://markmail.org/message/ittmrmwsn5l6usx7 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
