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]

Reply via email to