[jira] [Updated] (ISIS-1155) validate() vetoing - requiring rollback via the memento when editing - causes a ConcurrencyException to occur.

["Dan Haywood (JIRA)" <ji...@apache.org>]

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

Dan Haywood updated ISIS-1155:
------------------------------
    Fix Version/s:     (was: 1.10.0)
                   1.9.0

> validate() vetoing - requiring rollback via the memento when editing - causes a ConcurrencyException to occur.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ISIS-1155
>                 URL: https://issues.apache.org/jira/browse/ISIS-1155
>             Project: Isis
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: core-1.8.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 1.9.0
>
>
> For example, in the isisaddons' todoapp this shows up as an issue if mark an item (with a non-null dueBy) as done, then attempt to modify the dueBy date via edit.  What we see is no message shown, followed then by an invalid concurrency exception.
> With the simpleapp it's possible to get a similar behaviour.
> ~~~
> On analysis, there are several issues:
> - the concurrency exception is caused by the todo item becoming dirty when the change is applied (prior to being rolled back via Isis' memento); the todo item's adapter's Oid's version is updated as a side-effect of this (the postStore lifecycle callback), and thereafter we see the concurrency exception
> - this can in some cases be suppressed (eg for the simpleapp) by performing a rollback of the xactn if the validate() has failed... this should be done anyway
> - however in more complex cases (such as todoapp) the updating of the setVersion happens during the "apply()" of changes, which will still trigger the subsequent concurrency exception
> - the root cause here is that the memento being taken does not also reinstate the version of the target object.
> - the wicket viewer's EntityPropertiesForm was not passing through an AjaxRequestTarget for repainting [nb: this may be a red-herring, but fixing this does no harm]
> So, to sum up the fixes:
> - abort the xactn if validate() vetoes the save
> - improve the memento so that version is reinstated
> - pass through AjaxRequestTarget
> ~~~~~~~~
> Note that there is a related, not yet tackled issue... namely that validate() isn't enforced for action invocations, only when modifying an object by editing.  Have raised ISIS-1156 for this.



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