[
https://issues.apache.org/jira/browse/ISIS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574400#comment-14574400
]
ASF subversion and git services commented on ISIS-1155:
-------------------------------------------------------
Commit a16fcbbf78772489a646b6b65118945fff1c1096 in isis's branch
refs/heads/master from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=a16fcbb ]
ISIS-1155: fix for memento with validate(), to avoid incorrect
ConcurrencyException from being thrown.
> 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)
