Struts 2 Prepare Interceptor, CRUD Pattern and Optimistic Locking
Also posted to Struts 2 forum on Nabble - apologies if this causes a duplicate posting. Planning to use Struts 2 and JPA (OpenJPA) in a new application development and am spending some time to review options of how it should be done. There will be a large CRUD component within the application so I am working on the patterns to use in those scenarios. Following the CRUD examples in the Struts 2 In Action (and other sources), I have been experimenting with the ParamsPrepareParams stack. Using the pattern shown in the Struts 2 in Action book, the following is my understanding of the relevant points in the execution path. - when an edit (save) action is called the prepare() method retrieves the model object from the database (because there is an ID in the HTTP Request parameters). - the Params interceptor is invoked then loads the values from the HTTP Request parameters. None of the documentation describes why this is done, I assume the reason is to ensure that the Model object is fully populated (not all of the attributes may be on the UI and thus in the HTTP Request parameters). - the action is then invoked - and persists the updated Model object (delegated to a service) From what I can see, this causes a conflicts with the use of a version attribute for Optimistic Locking on the database. When the updates from the HTTP Request parameters are merged in with a newly retrieved model object the version number/timestamp is the value retrieved from the database. Even if that row had been updated by another user/thread since being retrieved the first time, the version checking would not catch the conflicting updates becuase it has been refreshed to the latest value in the DB. It seems a fairly fundamental and obvious problem so I am worried that I am mis-understanding the pattern described in the book (and repeated in other samples). I know that the examples in the book are simplified, but I would expect something like this to be commented on in the text. Am I missing something ??? Can anybody confirm or contradict my reasoning? -- View this message in context: http://www.nabble.com/Struts-2-Prepare-Interceptor%2C-CRUD-Pattern-and-Optimistic-Locking-tp19612252p19612252.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Prepare Interceptor, CRUD Pattern and Optimistic Locking
I agree that using the paramsPrepareParams is not the ideal stack to handle optimistic locking. However, assuming that you are not losing the original version number (for example if you are submitting it as a hidden field of your edit form), and you can reassign it to the appropriate POJO field through the parameters interceptor, at the end, if there is a conflict in version numbers between the original and the just loaded object, still you have all the necessary information to detect the conflict. 2008/9/22 Frank D. [EMAIL PROTECTED]: Also posted to Struts 2 forum on Nabble - apologies if this causes a duplicate posting. Planning to use Struts 2 and JPA (OpenJPA) in a new application development and am spending some time to review options of how it should be done. There will be a large CRUD component within the application so I am working on the patterns to use in those scenarios. Following the CRUD examples in the Struts 2 In Action (and other sources), I have been experimenting with the ParamsPrepareParams stack. Using the pattern shown in the Struts 2 in Action book, the following is my understanding of the relevant points in the execution path. - when an edit (save) action is called the prepare() method retrieves the model object from the database (because there is an ID in the HTTP Request parameters). - the Params interceptor is invoked then loads the values from the HTTP Request parameters. None of the documentation describes why this is done, I assume the reason is to ensure that the Model object is fully populated (not all of the attributes may be on the UI and thus in the HTTP Request parameters). - the action is then invoked - and persists the updated Model object (delegated to a service) From what I can see, this causes a conflicts with the use of a version attribute for Optimistic Locking on the database. When the updates from the HTTP Request parameters are merged in with a newly retrieved model object the version number/timestamp is the value retrieved from the database. Even if that row had been updated by another user/thread since being retrieved the first time, the version checking would not catch the conflicting updates becuase it has been refreshed to the latest value in the DB. It seems a fairly fundamental and obvious problem so I am worried that I am mis-understanding the pattern described in the book (and repeated in other samples). I know that the examples in the book are simplified, but I would expect something like this to be commented on in the text. Am I missing something ??? Can anybody confirm or contradict my reasoning? -- View this message in context: http://www.nabble.com/Struts-2-Prepare-Interceptor%2C-CRUD-Pattern-and-Optimistic-Locking-tp19612252p19612252.html Sent from the Struts - 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: Struts 2 Prepare Interceptor, CRUD Pattern and Optimistic Locking
Thanks for the response. I agree that there are a number of ways around the problem - I was just worried that I mis-understanding the sample. Gabriel Belingueres-2 wrote: I agree that using the paramsPrepareParams is not the ideal stack to handle optimistic locking. However, assuming that you are not losing the original version number (for example if you are submitting it as a hidden field of your edit form), and you can reassign it to the appropriate POJO field through the parameters interceptor, at the end, if there is a conflict in version numbers between the original and the just loaded object, still you have all the necessary information to detect the conflict. 2008/9/22 Frank D. [EMAIL PROTECTED]: Also posted to Struts 2 forum on Nabble - apologies if this causes a duplicate posting. Planning to use Struts 2 and JPA (OpenJPA) in a new application development and am spending some time to review options of how it should be done. There will be a large CRUD component within the application so I am working on the patterns to use in those scenarios. Following the CRUD examples in the Struts 2 In Action (and other sources), I have been experimenting with the ParamsPrepareParams stack. Using the pattern shown in the Struts 2 in Action book, the following is my understanding of the relevant points in the execution path. - when an edit (save) action is called the prepare() method retrieves the model object from the database (because there is an ID in the HTTP Request parameters). - the Params interceptor is invoked then loads the values from the HTTP Request parameters. None of the documentation describes why this is done, I assume the reason is to ensure that the Model object is fully populated (not all of the attributes may be on the UI and thus in the HTTP Request parameters). - the action is then invoked - and persists the updated Model object (delegated to a service) From what I can see, this causes a conflicts with the use of a version attribute for Optimistic Locking on the database. When the updates from the HTTP Request parameters are merged in with a newly retrieved model object the version number/timestamp is the value retrieved from the database. Even if that row had been updated by another user/thread since being retrieved the first time, the version checking would not catch the conflicting updates becuase it has been refreshed to the latest value in the DB. It seems a fairly fundamental and obvious problem so I am worried that I am mis-understanding the pattern described in the book (and repeated in other samples). I know that the examples in the book are simplified, but I would expect something like this to be commented on in the text. Am I missing something ??? Can anybody confirm or contradict my reasoning? -- View this message in context: http://www.nabble.com/Struts-2-Prepare-Interceptor%2C-CRUD-Pattern-and-Optimistic-Locking-tp19612252p19612252.html Sent from the Struts - 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] -- View this message in context: http://www.nabble.com/Struts-2-Prepare-Interceptor%2C-CRUD-Pattern-and-Optimistic-Locking-tp19612252p19616065.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
