On 1.12.11 12:05, Jukka Zitting wrote:
Hi,
On Thu, Dec 1, 2011 at 11:07 AM, Michael Dürig<[email protected]> wrote:
Note however, that for the same reason we are currently not able to
guarantee node type consistency:
[...]
Both sessions will successfully complete since for each of them the
consistency property (nt:file cannot have a child named "foo"). holds.
The save() implementation will need to do an internal refresh(true),
check any type and other constraints, and only persist the changes if
everything is OK.
To prevent this from being a too big blocking operation, we can use
optimistic locking by making the last step of the process conditional
on the repository still being at the state it was when the
refresh(true) call was made. Otherwise the refresh-check-persist cycle
should be restarted.
But this will introduce a race condition. With other words: this only
make the time window during which such a inconsistency could slip in
smaller. I think what we'd really need is an atomic test and set operation.
Michael
BR,
Jukka Zitting
