Re: Open Session in View Pattern: some basic questions
Igor, this clarified a lot. Many thanks for your very detailed reply. Kaspar On 26.03.2009, at 19:30, Igor Vaynberg 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]
Re: Open Session in View Pattern: some basic questions
On Thu, Mar 26, 2009 at 8:31 AM, Kaspar Fischer fisch...@inf.ethz.ch wrote: 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. My example doesn't use that pattern (called transaction-per-request). The OSIV filter in my example merely opens the session. I rely on @Transactional methods to begin/commit transactions for me. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
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.pdfcan=2q= [5] http://markmail.org/message/ittmrmwsn5l6usx7
Re: Open Session in View Pattern: some basic questions
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]
Re: Open Session in View Pattern: some basic questions
On Thu, Mar 26, 2009 at 5: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 ? Yes, that's a problem. That's why I just make sure I call @Transactional methods and let them begin/commit the transaction. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
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
Re: Open Session in View Pattern: some basic questions
On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: not if you buffer the response like wicket does by default :) Right, but you have to make sure your filters fire in the correct order, then. If your OSIV wraps around WicketFilter, then buffering won't fix the problem. The exception will happen after Wicket's done. Right? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
i already said OSIV that comes with spring doesnt support transaction-per-request, so what makes you think i am using it or any other filter? :) wicket has plenty of hooks to do this. -igor On Thu, Mar 26, 2009 at 3:36 PM, James Carman jcar...@carmanconsulting.com wrote: On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: not if you buffer the response like wicket does by default :) Right, but you have to make sure your filters fire in the correct order, then. If your OSIV wraps around WicketFilter, then buffering won't fix the problem. The exception will happen after Wicket's done. Right? - 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
