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]
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
