Hi,
On Wed, Feb 27, 2013 at 2:38 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Indeed. Here's my initial draft of what this could look like:
Committed the first version of this Editor mechanism in revision
1453738. See OAK-673 for further progress.
BR,
Jukka Zitting
Hi,
On Thu, Mar 7, 2013 at 11:16 AM, Thomas Mueller muel...@adobe.com wrote:
So, apart from problem a (which also affects the new MongoMK), the
current mechanism works fine (i.e. fully parallel writes) as long as
the changes are non-conflicting, but runs into trouble when there are
conflicts.
Hi,
I was referring to problem a, which is about validators and other
commit hooks not being a part of the underlying MK-level merge
operation and thus for example not always catching things like
duplicate UUIDs being introduced or hard references being broken (i.e.
repository invariants
On 7.3.13 11:08, Marcel Reutegger wrote:
Hi,
I was referring to problem a, which is about validators and other
commit hooks not being a part of the underlying MK-level merge
operation and thus for example not always catching things like
duplicate UUIDs being introduced or hard references
On Thu, Mar 7, 2013 at 1:08 PM, Marcel Reutegger mreut...@adobe.com
wrote:
as mentioned before, I think snapshot isolation is just fined because
in most cases it is sufficient and allows for increased concurrency. for
the cases where more consistency guarantees are needed, like
unique
Hi,
When encountering a case where the optimistic locking mechanism can't
push a commit through in say one second, instead of waiting for a
longer while I'd have the SegmentMK fall back to pessimistic locking
where it explicitly acquired a hard lock on the journal and does the
rebase/hook
Hi,
On Thu, Mar 7, 2013 at 2:10 PM, Marcel Reutegger mreut...@adobe.com wrote:
on the other hand I'm not sure this is really a good solution for the
second case. wouldn't the system quickly degrade into a serialized
execution with write locks on the journal?
It would, but you could solve that
Hi,
On Thu, Mar 7, 2013 at 2:24 PM, Marcel Reutegger mreut...@adobe.com wrote:
assuming the uniqueness constraint is enforced with the p2
index implementation in oak, each node with a distinct UUID,
will create a distinct index node for each UUID. creating those
nodes will not result in a
