-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: Session-per-request with Detached objects for Long Conversat
PostPosted: Thu Feb 18, 2010 7:17 pm 
Newbie

Joined: Thu Feb 18, 2010 7:14 pm
Posts: 3
I think I understand that if we use the Session-per-Request with Detached objects pattern for a long conversation for a single screen, where the user views and then changes some data then the following happens.
We have 2 Sessions/Transactions, the first reads the data required for viewing, and opensessioninviewfilter is used to prevent possible LazyInitializationException.
After the think time and the user submitting the modified data, then in the second Sessions/Transaction, the modified detached objects are reattached using session.saveorupdate(), and then at the end of the transaction, a version check will be done. The version check will cause this final transaction either to be committed if there has been no concurrent updates by another user since the long conversation started, but rolled back if there has been.
Firstly can I please confirm is that is correct ?
However, what if the long conversation consists of 2 screens, eg some sort of wizard.
In this case, which I presume will consist of 3 Sessions/Transactions ?
I also presume that the third transaction which runs after the user has submitted the 2nd and final screen, that like above, the detached objects will be reattached using session.saveorupdate() and the version check and commit/rollback will be done at the end of the transaction as above.
But what about the 2nd transaction, ie after the first screen is submitted. As well as reading data for the 2nd screen, does this need to reattach the detached objects presented in the first screen and modified by the user, and if so why ?
If so, then do you need to use lock() rather than saveorupdate() to prevent a version check and write to the database occurring at that point, ie as only want this to happen at the end of the long conversation ie after the 2nd screen has been submitted ?
Thanks very much in advance.


Top
 Profile  
 
 Post subject: Re: Session-per-request with Detached objects for Long Conversat
PostPosted: Fri Feb 19, 2010 6:15 am 
Beginner
Beginner

Joined: Wed Nov 21, 2007 8:02 am
Posts: 48
say you have a conversation with 3 requests

http Request1 : you read entity A
http Request2 : Modified entity A is posted and you read entity B,[ if you don't want the update to A to happen now, don't reattach entity A to the hibernate
session here, say you store modified entity A in http session]
http Request3 : Modified entity B submitted. Now you want the update to entity A and entity B to happen.
now retrieve entity A and reattach it the hibernate session, and also reattach entity B to the hibernate session.


Top
 Profile  
 
 Post subject: Re: Session-per-request with Detached objects for Long Conversat
PostPosted: Sat Feb 20, 2010 12:25 am 
Newbie

Joined: Thu Feb 18, 2010 7:14 pm
Posts: 3
Thanks very much for the reply


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.