[
https://issues.apache.org/jira/browse/ISIS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837028#comment-13837028
]
Dan Haywood commented on ISIS-620:
----------------------------------
Just to restate the scenario (I had to read it a couple of times to get it):
a. the user is working with some entity, eg Order
b. they realise they now need a Product to complete what they were working on,
which they do, using Products>newProduct, and end up at the Product entity
c. they now press back button to get to step (a), whereupon
d. they get a concurrency exception when they interact with the Order.
Some further ideas:
4. if the concurrency exception is because of the same user, we could ignore
"sven attempted to update TODO:L_23, however this object has since been
modified by sven at Mon Dec 02 18:13:13 CET 2013 [3 vs 2]"... if it was
modified by sven and sven is updating, then let it through
5. when go back to entity, do a proactive check to see it is stale, and reload
if necessary. Not exactly sure how to do that, though.
> When editing an entity twice a concurrency exception is thrown
> --------------------------------------------------------------
>
> Key: ISIS-620
> URL: https://issues.apache.org/jira/browse/ISIS-620
> Project: Isis
> Issue Type: Bug
> Components: Viewer: Wicket
> Affects Versions: viewer-wicket-1.3.1
> Reporter: Jeroen van der Wal
> Assignee: Dan Haywood
> Fix For: viewer-wicket-1.4.0
>
>
> When editing an entity twice a concurrency exception is thrown when using the
> backspace (browser back) anywhere in the application.
> To reproduce:
> * load fixtures
> * open arbitrary todo
> * click edit, change description, click save
> * again, click edit, change description, click save
> The result:
> sven attempted to update TODO:L_23, however this object has since been
> modified by sven at Mon Dec 02 18:13:13 CET 2013 [3 vs 2]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
