You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2015/06/05 14:08:01 UTC

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

Dan Haywood created ISIS-1155:
---------------------------------

             Summary: 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)