[jira] [Updated] (TAP5-1534) BeanEditForm should handle @Version fields (hibernate optimistic locking)

["Josh Canfield (JIRA)" <ji...@apache.org>]

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

Josh Canfield updated TAP5-1534:
--------------------------------

    Component/s:     (was: tapestry-core)
                 tapestry-hibernate

Moved to tapestry-hibernate for hibernate specific issue

> 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.4, 5.2.5
>            Reporter: Donny Nadolny
>            Priority: Minor
>
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira