[
https://jira.nuxeo.com/browse/NXP-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=88294#action_88294
]
Florent Guillaume commented on NXP-6054:
----------------------------------------
Changed locking mechanism to go through a single serializing LockingManager
(per repository) in a separate thread in order to enforce unique locking
semantics.
This means that it's now impossible to have two session thinking locking the
same document at the same time. Previously it was possible in edge cases when
race conditions occurred.
http://hg.nuxeo.org/nuxeo/nuxeo-core/rev/a2d8128d1a4f
> Better lock format to store user and timestamp
> ----------------------------------------------
>
> Key: NXP-6054
> URL: https://jira.nuxeo.com/browse/NXP-6054
> Project: Nuxeo Enterprise Platform
> Issue Type: Improvement
> Components: Core, Core SQL Storage
> Affects Versions: 5.3.2
> Reporter: Florent Guillaume
> Assignee: Florent Guillaume
> Priority: Major
> Fix For: 5.4.1
>
>
> Currently the lock API is
> CoreSession.setLock(DocumentRef docRef, String key)
> Where the key is of the form "jdoe" or "jdoe:Nov 29, 2010" and has to be
> generated by the caller.
> Conversely the getLock() API returns a String that has to be parsed if we
> want to extract the date.
> Problems:
> - there's many repeated places where date generation/parsing occurs,
> - it's not possible to store a precise timestamp.
> -> Change the lock API to generate the timestamp automatically, and provide
> an API that returns it.
> Also, store the timestamp in the database in a proper column (with database
> migration).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.nuxeo.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
