[
https://issues.apache.org/jira/browse/ATLAS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222110#comment-15222110
]
David Kantor commented on ATLAS-496:
------------------------------------
Continuing previous comment...
With optimistic locking, there could be a lock ID value on each entity which is
incremented whenever the entity is updated. This lock ID would be part of the
object state returned clients when they retrieve an entity. When applying a
full update, that lock ID would included in the entity state used for the
update, and then checked against the persisted state of the entity to see if
there is a match. If the persisted lock ID is greater than the value passed in
by the client, that indicates another user had updated the object, and the
object state being used for the update is stale and the update should be
disallowed.
> Optimistic locking to prevent update conflicts
> ----------------------------------------------
>
> Key: ATLAS-496
> URL: https://issues.apache.org/jira/browse/ATLAS-496
> Project: Atlas
> Issue Type: Improvement
> Reporter: David Kantor
>
> The ATLAS api does not adequately protect against concurrent activity against
> the same entity, type or other object.
> Some form of locking is desirable, though strict locking and/or 2pc are
> problematic in a highly distributed environment. Optimistic locking may be
> the best approach so that at a minimum an application attempting to do a
> modification will be alerted if another application has touched the same
> (object) since that app last retrieved the object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
