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]
