Struts2 Conversation/OptimisticLockException Handling

["CRANFORD, CHRIS" <Ch...@setech.com>]

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?

Re: Struts2 Conversation/OptimisticLockException Handling

[Antonios Gkogkakis <gk...@tcd.ie>]

Hi Chris,
I don't see the need of a conversation plugin, you can just use the http
session to store your detached object.

So the flow will be, user requests a page, you load all the domain objects
using JPA and you detach them. (Closing the EntityManager does that). Then
you put them in the session and return the form to the user, which uses the
instances of your domain objects stored in the session, to populate its
fields.

User submit changes which you store on another instance of the domain class
in your action. Then you start your JPA transaction, and you merge the
detached object which you get from the session. At this point if someone
has changed it in the database, the merge will throw an
OptimistickLockException and you can inform the user that someone has
modified the object. If not you copy the changes from the instance of your
domain class that you just submitted to,  to the detached object and commit
the transaction.

Hope it helps.

Antonios








On 16 November 2013 02:47, Gabriel Belingueres <be...@gmail.com>wrote:

> Hi Chris.
>
> One alternative is to use CDI which supports conversation scope too (I know
> there is a CDI plugin. I never used though). Last time I checked the
> spring-
> webflow integration was pretty outdated (it did not integrate with version
> 2.x). Another alternative is to go use JBoss Seam.
>
> I made myself a conversation plugin which used successfully in some small
> projects (I promised myself to publish the code sometime...I need to polish
> it a little and translate it to english first). The great thing about
> conversations is that you get almost for free the "extended persistent
> context", that is the entity manager itself is stored inside the current
> conversation along with your domain object (which remain attached to this
> persistent context) and then you just use your forms without rewriting the
> version number. Before the conversation ends, the entity manager is flushed
> and a version conflict can be detected.
>
>
> HTH,
> Gabriel
>
>
> 2013/11/15 CRANFORD, CHRIS <Ch...@setech.com>
>
> > 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?
> >
> >
>

Re: Struts2 Conversation/OptimisticLockException Handling

[Gabriel Belingueres <be...@gmail.com>]

Hi Chris.

One alternative is to use CDI which supports conversation scope too (I know
there is a CDI plugin. I never used though). Last time I checked the spring-
webflow integration was pretty outdated (it did not integrate with version
2.x). Another alternative is to go use JBoss Seam.

I made myself a conversation plugin which used successfully in some small
projects (I promised myself to publish the code sometime...I need to polish
it a little and translate it to english first). The great thing about
conversations is that you get almost for free the "extended persistent
context", that is the entity manager itself is stored inside the current
conversation along with your domain object (which remain attached to this
persistent context) and then you just use your forms without rewriting the
version number. Before the conversation ends, the entity manager is flushed
and a version conflict can be detected.


HTH,
Gabriel


2013/11/15 CRANFORD, CHRIS <Ch...@setech.com>

> 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?
>
>