cubicweb #197665 locking strategies for concurrent edition [resolved]
In order to prevent concurrent users to alter simultaneously the same resource.
Either pessimistic locking (reserve the resource for the 1rst user and prevent access to the 2nd user), or optimistic locking (reject the 2nd commit tentative). User(s) whose transaction has been rejected/rollbacked must be warned.
|closed by||<not specified>|
- cubicweb #901407 support for backup/restore of bfss
- cubicweb #1806898 ical view: UID is not unique across generations of the view
- cubicweb #197668 database replication for readonly access
- cubicweb #344897 wrong ticket creation date in project principal view
- cubicweb-forge #1399287 Change the standard validation process of the tickets