struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CRANFORD, CHRIS" <Chris.Cranf...@setech.com>
Subject Struts2 Conversation/OptimisticLockException Handling
Date Fri, 15 Nov 2013 22:07:38 GMT
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?


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message