On 27.11.14 11:54 , Michael Marth wrote:
Hi,
OAK-2287 made me think if we should generalise the approach
implemented in OAK-2287 (which is just for jcr:lastModified) in order
to make conflict handling more clever.
For example, consider a property myapp:lastActivated (a time stamp).
Should we allow such application logic to specify for the conflict
handler that the last write (highest value) always wins? There could
be complications like another property myapp:lastActivatedBy (a user
name) where also the last value should win for the node to be in a
consistent state.
So overall, I am really not sure if this is a good idea or if we need
it at all. Any thoughts?
Hi,
In general I think we should be conservative with adding conflict
handling logic on the Oak layer. Resolving conflicts relies on the
semantics of the data and that is not know at the persistence layer. The
conflict handlers we currently have are for handling tree conflicts
(node/property additions/removals/changes) and that's precisely the part
of the semantics we deal with at the persistence layer: trees.
Adding conflict handlers for date properties is a bit borderline. As
Alex pointed out not all dates are equal: when for jcr:lastModified you
want to give that later date precedence, for jcr:created it is the
earlier.
Furthermore I fear that we might be setting the wrong expectations here.
In a clustered environment we so far don't have a requirement for
synchronised system clocks. Once we start relying on time stamps we
either have that requirement or start seeing "interesting" merge results.
Long story short: I think we should add better merging for
jcr:lastModified and jcr:created (aka OAK-2287) notwithstanding my
concerns in the preceding paragraph but we should not generalise it to
other date properties. Nevertheless could we make conflict handling in
Oak more pluggable so applications could reuse such logic for their
dates properties as needed.
Or even shorter: yes.
Michael
