[ 
https://issues.apache.org/jira/browse/TAP5-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jochen Kemnade closed TAP5-1534.
--------------------------------
    Resolution: Invalid

We assume this is no longer relevant and therefore close it.
If you still have this issue in a recent Tapestry version (such as 5.3.8 or the 
latest 5.4 preview release), feel free to provide the necessary information and 
reopen.

> BeanEditForm should handle @Version fields (hibernate optimistic locking)
> -------------------------------------------------------------------------
>
>                 Key: TAP5-1534
>                 URL: https://issues.apache.org/jira/browse/TAP5-1534
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-hibernate
>    Affects Versions: 5.2
>            Reporter: Donny Nadolny
>            Priority: Minor
>              Labels: bulk-close-candidate
>
> A BeanEditForm for a hibernate entity with a field annotated with @Version 
> (the optimistic locking strategy) should be handled correctly by tapestry. 
> Right now, it is possible to load a page with a BeanEditForm, and if the 
> underlying entity is modified before the form is saved (in the 
> minutes/hours/days that the page is open), the form changes will overwrite 
> other changes. This is not supposed to happen when a Hibernate entity uses a 
> version field.
> There are some possible solutions at 
> https://forum.hibernate.org/viewtopic.php?f=1&t=957807
> To reproduce this, create an entity with a version field and a page with a 
> BeanEditForm for it. Open the page, change the version (in the database if 
> you aren't using a caching layer, or via the application if you are), and 
> then save the form. The expected result is a StaleObjectStateException, but 
> instead the changes are overwritten, defeating Hibernate's optimistic locking 
> strategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to