You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by cretzel <ma...@gmail.com> on 2008/06/25 17:51:59 UTC
OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Hi,
I'm using Wicket together with Spring and Hibernate. And it's quite common,
I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel
which wraps the domain objects loaded with Hibernate, so that when the model
is detached it only holds the ID of the domain object and when its
load()-method is called it uses the ID to load the entity again from the
database (see
http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351
this post for an example). So one advantage of this pattern is that you
mainly never get into problems with detached entities
(LazyInitializingException and so on).
I only got one issue with this when using Spring's transaction support.
Suppose you are editing a domain object in a form and you submit the form
and it passes conversion and validation. Actually the changes you've made
have been written into the domain object when you are in onSubmit() for
example. Then in this situation these changes could easily get persistet to
the DB, even if you don't want them to at this point, e.g. because you want
to do some backend validation first. This can happen when Hibernate flushes
the session, for example before another query. The problem is that the
changes on the domain object are made outside of a transaction
[OpenSessionInViewFilter just opens a Session but doesn't start a
transaction].
An example:
Suppose you are editing an entity User, changing the username for example.
The onSubmit()-method could look like this:
onSubmit() {
// User with changed username, attached to the Session
User user = (User) getModelObject();
// Do a query. This will cause the changes made to user
// to be flushed to the DB
userService.getUsers();
// This method does some backend validation, possibly
// fails and the transaction is rolled back so that the
// changes should not be persisted
userService.saveUser(user);
}
After this, the changes could be persistent in the DB, although they
shouldn't because the validation in the backend failed which should have
rolled back the changes.
I hope I made clear the point.
What do you think?
--
View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115802.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and
Transactions
Posted by cretzel <ma...@gmail.com>.
you are right. That's the reason of using OSIV, although these two concepts
are somewhat related to each other. I mean, when you are not using OSIV, you
have to collect all the data you want to display on the presentation tier
within a facade, for example. One possiblity is then to
(Hibernate-)initialize all needed entities and expose the domain model to
the presentation tier, the other one is using DTOs that carry the data.
igor.vaynberg wrote:
>
> no, the point of osiv is that you can use the beans you loaded even
> after the transactions has ended without getting lazyload exceptions.
> it has nothing to do with writing changes or not having to use dtos.
>
Anyway,
igor.vaynberg wrote:
>
>> map a form to a bean and apply the changes to the entity yourself
>
is quite the same as writing DTOs, isn't it?
--
View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18140832.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by Igor Vaynberg <ig...@gmail.com>.
no, the point of osiv is that you can use the beans you loaded even
after the transactions has ended without getting lazyload exceptions.
it has nothing to do with writing changes or not having to use dtos.
-igor
On Thu, Jun 26, 2008 at 1:30 AM, cretzel <ma...@gmail.com> wrote:
>
> Thanks for the immediate replies.
>
> Seems that, when using that pattern, one really always has to be aware of
> the fact that changes are made directly to persistent instances. Otherwise
> it could easily happen to get inconsistent data into the DB.
>
>
> Michael Sparer wrote:
>>
>> I'd say either enable transactions only for write operations or put all
>> together in one transaction (i.e. don't let hibernate flush the session
>> before you did your backend checks) ...
>>
>
> This works if each request is a single transaction. If multiple transactions
> are run in one request, this wouldn't help, I think.
>
>
> igor.vaynberg wrote:
>>
>> map a form to a bean and apply the changes to the entity yourself or do
>> all validation via I(Form)Validators
>>
>
> The first solution sounds like using DTOs and one reason of using OSIV is to
> not to have to use DTOs.
>
> But I like the FormValidator solution. That should work in most cases.
>
> Regards
>
>
>
> --
> View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Yes, thats true. It's a thing to watch out for.. Someone suggested that
you could use maps to contain your temporary variables in (a lot easier
than having duplicate classes), and you can use that as well in compound
models etc..
cretzel wrote:
> Thanks for the immediate replies.
>
> Seems that, when using that pattern, one really always has to be aware of
> the fact that changes are made directly to persistent instances. Otherwise
> it could easily happen to get inconsistent data into the DB.
>
>
> Michael Sparer wrote:
>
>> I'd say either enable transactions only for write operations or put all
>> together in one transaction (i.e. don't let hibernate flush the session
>> before you did your backend checks) ...
>>
>>
>
> This works if each request is a single transaction. If multiple transactions
> are run in one request, this wouldn't help, I think.
>
>
> igor.vaynberg wrote:
>
>> map a form to a bean and apply the changes to the entity yourself or do
>> all validation via I(Form)Validators
>>
>>
>
> The first solution sounds like using DTOs and one reason of using OSIV is to
> not to have to use DTOs.
>
> But I like the FormValidator solution. That should work in most cases.
>
> Regards
>
>
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by James Carman <ja...@carmanconsulting.com>.
If it's set to FlushMode.NEVER, then it won't flush after the requests
are finished.
On Thu, Jun 26, 2008 at 8:00 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> Yeah, I believe it's flushed after requests right? But that's also good
> enough since validation should have stopped unwanted values from comming
> in..
>
>
> He could try to use the wicket Iolite archetype for this, should be simple
> to see, and Im very sure that he will see that only validated values are in
> his objects...
>
> James Carman wrote:
>>
>> Are you positive that hibernate will write this data to the session?
>> The default flush mode of Spring's OpenSessionInViewFilter is "NEVER":
>>
>>
>> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html#setFlushMode(org.hibernate.FlushMode)
>>
>> I would try a simple test. Create a form that edits a bean that you
>> retrieve from the database (you retrieve it using a DAO/Repository
>> with a transaction demarcation of readOnly/required). Try to edit the
>> object but have it fail validation (don't set a required field or
>> something). Then, check your db to see if the values are there.
>>
>>
>> On Thu, Jun 26, 2008 at 4:30 AM, cretzel <ma...@gmail.com>
>> wrote:
>>
>>>
>>> Thanks for the immediate replies.
>>>
>>> Seems that, when using that pattern, one really always has to be aware of
>>> the fact that changes are made directly to persistent instances.
>>> Otherwise
>>> it could easily happen to get inconsistent data into the DB.
>>>
>>>
>>> Michael Sparer wrote:
>>>
>>>>
>>>> I'd say either enable transactions only for write operations or put all
>>>> together in one transaction (i.e. don't let hibernate flush the session
>>>> before you did your backend checks) ...
>>>>
>>>>
>>>
>>> This works if each request is a single transaction. If multiple
>>> transactions
>>> are run in one request, this wouldn't help, I think.
>>>
>>>
>>> igor.vaynberg wrote:
>>>
>>>>
>>>> map a form to a bean and apply the changes to the entity yourself or do
>>>> all validation via I(Form)Validators
>>>>
>>>>
>>>
>>> The first solution sounds like using DTOs and one reason of using OSIV is
>>> to
>>> not to have to use DTOs.
>>>
>>> But I like the FormValidator solution. That should work in most cases.
>>>
>>> Regards
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> 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: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Yeah, I believe it's flushed after requests right? But that's also good
enough since validation should have stopped unwanted values from comming
in..
He could try to use the wicket Iolite archetype for this, should be
simple to see, and Im very sure that he will see that only validated
values are in his objects...
James Carman wrote:
> Are you positive that hibernate will write this data to the session?
> The default flush mode of Spring's OpenSessionInViewFilter is "NEVER":
>
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html#setFlushMode(org.hibernate.FlushMode)
>
> I would try a simple test. Create a form that edits a bean that you
> retrieve from the database (you retrieve it using a DAO/Repository
> with a transaction demarcation of readOnly/required). Try to edit the
> object but have it fail validation (don't set a required field or
> something). Then, check your db to see if the values are there.
>
>
> On Thu, Jun 26, 2008 at 4:30 AM, cretzel <ma...@gmail.com> wrote:
>
>> Thanks for the immediate replies.
>>
>> Seems that, when using that pattern, one really always has to be aware of
>> the fact that changes are made directly to persistent instances. Otherwise
>> it could easily happen to get inconsistent data into the DB.
>>
>>
>> Michael Sparer wrote:
>>
>>> I'd say either enable transactions only for write operations or put all
>>> together in one transaction (i.e. don't let hibernate flush the session
>>> before you did your backend checks) ...
>>>
>>>
>> This works if each request is a single transaction. If multiple transactions
>> are run in one request, this wouldn't help, I think.
>>
>>
>> igor.vaynberg wrote:
>>
>>> map a form to a bean and apply the changes to the entity yourself or do
>>> all validation via I(Form)Validators
>>>
>>>
>> The first solution sounds like using DTOs and one reason of using OSIV is to
>> not to have to use DTOs.
>>
>> But I like the FormValidator solution. That should work in most cases.
>>
>> Regards
>>
>>
>>
>> --
>> View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and
Transactions
Posted by cretzel <ma...@gmail.com>.
jwcarman wrote:
>
> Are you positive that hibernate will write this data to the session?
> The default flush mode of Spring's OpenSessionInViewFilter is "NEVER":
>
> ... you retrieve it using a DAO/Repository with a transaction demarcation
> of readOnly/required ...
>
yeah, that's right. But there are some use cases where Hibernate *will*
flush. For example Hibernate will flush when calling a service method (not
read-only) that for some reason decides not to save the user, e.g.
public void checkAndSaveUser(User u) {
if (user.getUsername().length() > 3) saveOrUpdate(u);
}
This will flush at the end of the transaction.
Another situation is where you start multiple transaction, e.g. to register
a user to different groups.
public void onSubmit() {
User user = (User) getModelObject();
for (Group group : user.getGroups()) {
service.registerUserForGroup(user, group);
}
}
I agree, these might be some strange examples. But the point is, if you
don't want changes to be persisted, you have to take care that between the
beginning and the end of the request there are no (non-read-only)
transactional service methods called. [As mentioned, the OSIV-Filter
defaults to FlushMode.NEVER, so it won't flush by itself].
Another possibility is to use Wicket's validation capabilities, as Igor
mentioned. Unlike other frameworks (I think Spring MVC is an example),
Wicket validators get called before anything is written in to the model
objects. So it's okay to call service methods from those validators.
--
View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18140556.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by James Carman <ja...@carmanconsulting.com>.
Are you positive that hibernate will write this data to the session?
The default flush mode of Spring's OpenSessionInViewFilter is "NEVER":
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html#setFlushMode(org.hibernate.FlushMode)
I would try a simple test. Create a form that edits a bean that you
retrieve from the database (you retrieve it using a DAO/Repository
with a transaction demarcation of readOnly/required). Try to edit the
object but have it fail validation (don't set a required field or
something). Then, check your db to see if the values are there.
On Thu, Jun 26, 2008 at 4:30 AM, cretzel <ma...@gmail.com> wrote:
>
> Thanks for the immediate replies.
>
> Seems that, when using that pattern, one really always has to be aware of
> the fact that changes are made directly to persistent instances. Otherwise
> it could easily happen to get inconsistent data into the DB.
>
>
> Michael Sparer wrote:
>>
>> I'd say either enable transactions only for write operations or put all
>> together in one transaction (i.e. don't let hibernate flush the session
>> before you did your backend checks) ...
>>
>
> This works if each request is a single transaction. If multiple transactions
> are run in one request, this wouldn't help, I think.
>
>
> igor.vaynberg wrote:
>>
>> map a form to a bean and apply the changes to the entity yourself or do
>> all validation via I(Form)Validators
>>
>
> The first solution sounds like using DTOs and one reason of using OSIV is to
> not to have to use DTOs.
>
> But I like the FormValidator solution. That should work in most cases.
>
> Regards
>
>
>
> --
> View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: OpenSessionInView (OSIV), LoadableDetachableModel and
Transactions
Posted by cretzel <ma...@gmail.com>.
Thanks for the immediate replies.
Seems that, when using that pattern, one really always has to be aware of
the fact that changes are made directly to persistent instances. Otherwise
it could easily happen to get inconsistent data into the DB.
Michael Sparer wrote:
>
> I'd say either enable transactions only for write operations or put all
> together in one transaction (i.e. don't let hibernate flush the session
> before you did your backend checks) ...
>
This works if each request is a single transaction. If multiple transactions
are run in one request, this wouldn't help, I think.
igor.vaynberg wrote:
>
> map a form to a bean and apply the changes to the entity yourself or do
> all validation via I(Form)Validators
>
The first solution sounds like using DTOs and one reason of using OSIV is to
not to have to use DTOs.
But I like the FormValidator solution. That should work in most cases.
Regards
--
View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
you could take a look at blog tutorial(wiki) or wicket iolite(wicket
stuff)...
cretzel wrote:
> Hi,
>
> I'm using Wicket together with Spring and Hibernate. And it's quite common,
> I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel
> which wraps the domain objects loaded with Hibernate, so that when the model
> is detached it only holds the ID of the domain object and when its
> load()-method is called it uses the ID to load the entity again from the
> database (see
> http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351
> this post for an example). So one advantage of this pattern is that you
> mainly never get into problems with detached entities
> (LazyInitializingException and so on).
>
> I only got one issue with this when using Spring's transaction support.
> Suppose you are editing a domain object in a form and you submit the form
> and it passes conversion and validation. Actually the changes you've made
> have been written into the domain object when you are in onSubmit() for
> example. Then in this situation these changes could easily get persistet to
> the DB, even if you don't want them to at this point, e.g. because you want
> to do some backend validation first. This can happen when Hibernate flushes
> the session, for example before another query. The problem is that the
> changes on the domain object are made outside of a transaction
> [OpenSessionInViewFilter just opens a Session but doesn't start a
> transaction].
>
> An example:
> Suppose you are editing an entity User, changing the username for example.
> The onSubmit()-method could look like this:
>
> onSubmit() {
> // User with changed username, attached to the Session
> User user = (User) getModelObject();
> // Do a query. This will cause the changes made to user
> // to be flushed to the DB
> userService.getUsers();
> // This method does some backend validation, possibly
> // fails and the transaction is rolled back so that the
> // changes should not be persisted
> userService.saveUser(user);
> }
>
> After this, the changes could be persistent in the DB, although they
> shouldn't because the validation in the backend failed which should have
> rolled back the changes.
>
> I hope I made clear the point.
>
> What do you think?
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and
Transactions
Posted by Michael Sparer <mi...@gmx.at>.
I'd say either enable transactions only for write operations or put all
together in one transaction (i.e. don't let hibernate flush the session
before you did your backend checks) ...
cretzel wrote:
>
> Hi,
>
> I'm using Wicket together with Spring and Hibernate. And it's quite
> common, I think, to use an OpenSessionInViewFilter and a
> LoadableDetachableModel which wraps the domain objects loaded with
> Hibernate, so that when the model is detached it only holds the ID of the
> domain object and when its load()-method is called it uses the ID to load
> the entity again from the database (see
> http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351
> this post for an example). So one advantage of this pattern is that you
> mainly never get into problems with detached entities
> (LazyInitializingException and so on).
>
> I only got one issue with this when using Spring's transaction support.
> Suppose you are editing a domain object in a form and you submit the form
> and it passes conversion and validation. Actually the changes you've made
> have been written into the domain object when you are in onSubmit() for
> example. Then in this situation these changes could easily get persistet
> to the DB, even if you don't want them to at this point, e.g. because you
> want to do some backend validation first. This can happen when Hibernate
> flushes the session, for example before another query. The problem is that
> the changes on the domain object are made outside of a transaction
> [OpenSessionInViewFilter just opens a Session but doesn't start a
> transaction].
>
> An example:
> Suppose you are editing an entity User, changing the username for example.
> The onSubmit()-method could look like this:
>
> onSubmit() {
> // User with changed username, attached to the Session
> User user = (User) getModelObject();
> // Do a query. This will cause the changes made to user
> // to be flushed to the DB
> userService.getUsers();
> // This method does some backend validation, possibly
> // fails and the transaction is rolled back so that the
> // changes should not be persisted
> userService.saveUser(user);
> }
>
> After this, the changes could be persistent in the DB, although they
> shouldn't because the validation in the backend failed which should have
> rolled back the changes.
>
> I hope I made clear the point.
>
> What do you think?
>
>
-----
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115882.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Posted by Igor Vaynberg <ig...@gmail.com>.
map a form to a bean and apply the changes to the entity yourself
or do all validation via I(Form)Validators
-igor
On Wed, Jun 25, 2008 at 8:51 AM, cretzel <ma...@gmail.com> wrote:
>
> Hi,
>
> I'm using Wicket together with Spring and Hibernate. And it's quite common,
> I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel
> which wraps the domain objects loaded with Hibernate, so that when the model
> is detached it only holds the ID of the domain object and when its
> load()-method is called it uses the ID to load the entity again from the
> database (see
> http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351
> this post for an example). So one advantage of this pattern is that you
> mainly never get into problems with detached entities
> (LazyInitializingException and so on).
>
> I only got one issue with this when using Spring's transaction support.
> Suppose you are editing a domain object in a form and you submit the form
> and it passes conversion and validation. Actually the changes you've made
> have been written into the domain object when you are in onSubmit() for
> example. Then in this situation these changes could easily get persistet to
> the DB, even if you don't want them to at this point, e.g. because you want
> to do some backend validation first. This can happen when Hibernate flushes
> the session, for example before another query. The problem is that the
> changes on the domain object are made outside of a transaction
> [OpenSessionInViewFilter just opens a Session but doesn't start a
> transaction].
>
> An example:
> Suppose you are editing an entity User, changing the username for example.
> The onSubmit()-method could look like this:
>
> onSubmit() {
> // User with changed username, attached to the Session
> User user = (User) getModelObject();
> // Do a query. This will cause the changes made to user
> // to be flushed to the DB
> userService.getUsers();
> // This method does some backend validation, possibly
> // fails and the transaction is rolled back so that the
> // changes should not be persisted
> userService.saveUser(user);
> }
>
> After this, the changes could be persistent in the DB, although they
> shouldn't because the validation in the backend failed which should have
> rolled back the changes.
>
> I hope I made clear the point.
>
> What do you think?
>
> --
> View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115802.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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