[
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)