Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
