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
