[
https://issues.apache.org/jira/browse/ISIS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887790#comment-16887790
]
ASF subversion and git services commented on ISIS-2154:
-------------------------------------------------------
Commit 94cb06afdea40a5f0e454826a0fd068d0c80d77e in isis's branch refs/heads/v2
from Andi Huber
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=94cb06a ]
ISIS-2154 cleanup some debug code
> Remove support for persistent object concurrency checking
> ---------------------------------------------------------
>
> Key: ISIS-2154
> URL: https://issues.apache.org/jira/browse/ISIS-2154
> Project: Isis
> Issue Type: Improvement
> Reporter: Andi Huber
> Assignee: Andi Huber
> Priority: Major
> Fix For: 2.0.0
>
>
> Concurrency Checking:
> The OID contains the version/timestamp of the object as retrieved from the
> DB.So there's a potential race condition if two users pull back the same
> object at the same time.not to view, but instead when they hit OK to invoke
> an action (the same action, or perhaps different, but at any rate on the same
> target object). Both of those users actions will pull back the object with
> the same version, but either one or the other will commit first, thereby
> bumping the version.
> The race condition here is gonna be measured in milliseconds - it's the time
> between pulling an object back in order to interact with it, and then the
> transaction locking it out.
> So, once the first user's transaction has completed, then the second user can
> interact with that object.
> The concurrency check is to ensure that the object hasn't been modified
> since... and if it has, then to require the second unlucky user to start over.
> This mechanism only protects the target object, but says nothing about the
> version of any other objects that might be involved in the transaction.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
