Recently I was looking at a particular pattern we used and noticed that it 
exposed a bit of risk.

In the past we generally queried our domain object, showed the user the form 
where they could maintain the record and within a hidden field, we maintained 
the version of that record.  During the submission, the database record was 
queried again, the changes applied to the entity, including the version from 
the form.  Should another user had modified the same record in between this 
session's save, naturally a collision would have been detected by the JPA 
framework.

It was suggested that rather than expose the version and reset it during the 
submission phase, why not just cache the original fetched object, set the 
values on that object during save and persist the saved object when the time 
occurs.  To do this, there has to be some link between the cached version of 
the object and the requests, hence some conversation framework.

I stumbled across struts2-conversation plugin that seems to offer this 
functionality and I know of spring-webflow.

Are there other alternatives anyone has used?  Anyone have experiences they can 
share regarding the struts2-conversation plugin or integrating spring-webflow 
with Struts2?  Or have you simply just exposed the version in your forms and 
resent it back with every on submit, finding your domain object, detaching it, 
making changes (including setting your version), and the merging it back to be 
able to catch OptimisticLockException exceptions during database collisions?

Reply via email to