You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Kaspar Fischer <fi...@inf.ethz.ch> on 2009/03/26 13:31:38 UTC
Open Session in View Pattern: some basic questions
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by James Carman <jc...@carmanconsulting.com>.
On Thu, Mar 26, 2009 at 8:31 AM, Kaspar Fischer <fi...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by Kaspar Fischer <fi...@inf.ethz.ch>.
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
> <fi...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<jc...@carmanconsulting.com> wrote:
> On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg <ig...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by James Carman <jc...@carmanconsulting.com>.
On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg <ig...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by Igor Vaynberg <ig...@gmail.com>.
not if you buffer the response like wicket does by default :)
-igor
On Thu, Mar 26, 2009 at 2:34 PM, Maarten Bosteels
<mb...@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 <ig...@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 <fi...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by James Carman <jc...@carmanconsulting.com>.
On Thu, Mar 26, 2009 at 5:34 PM, Maarten Bosteels
<mb...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by Maarten Bosteels <mb...@gmail.com>.
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 <ig...@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 <fi...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Open Session in View Pattern: some basic questions
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <fi...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org