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