Hi,
On Thu, Mar 7, 2013 at 2:05 PM, Michael Dürig wrote:
> Yes I'm also a bit worried about this. Couldn't this lead to cascading
> undos? And further to violation of other application constraints when data
> gets "uncommited"? I think this is a very slippery slope...
The way I see it, the norma
Hi,
> But it doesn't address the other case I brought up, of adding a write
> restriction on the root node. It's a very rare commit that does do
> something like that, but any commits need to be aware of potential
> changes in that area. Thus, if we want to maintain the illusion of
> serialization
Hi,
On Thu, Mar 7, 2013 at 2:24 PM, Marcel Reutegger 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 conflict as define
> On Thu, Mar 7, 2013 at 1:57 PM, Marcel Reutegger
> wrote:
> > not necessarily. e.g. if we take the unique UUID as an example,
> > two sessions can proceed concurrently when they create nodes
> > with different UUIDs, which is usually the case. the conflict only
> > materializes when you create t
Hi,
On Thu, Mar 7, 2013 at 1:57 PM, Marcel Reutegger wrote:
> not necessarily. e.g. if we take the unique UUID as an example,
> two sessions can proceed concurrently when they create nodes
> with different UUIDs, which is usually the case. the conflict only
> materializes when you create two node
On 7.3.13 11:57, Marcel Reutegger wrote:
On Thu, Mar 7, 2013 at 1:08 PM, Marcel Reutegger
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 neede
> On Thu, Mar 7, 2013 at 1:08 PM, Marcel Reutegger
> 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 UUIDs and h
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 bein
Hi,
On Thu, Mar 7, 2013 at 1:08 PM, Marcel Reutegger 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 UUIDs and hard ref
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
Hi,
On Thu, Mar 7, 2013 at 11:16 AM, Thomas Mueller 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.
>
> Sorry I d
Hi,
>However, as noted in OAK-633, there are a few conceptual problems with
>this approach to processing merges:
>
>a) Since validators and other commit hooks are not run during the
>merge, the result can be an internally inconsistent content tree
>(dangling references, incorrect permission store,
Hi,
On Wed, Mar 6, 2013 at 5:33 PM, Thomas Mueller wrote:
> I wonder what is the state of the implementation of merge operations for
> segments and journals, and how are merges scheduled?
Basic merging functionality for the in-memory segment store there, see
the o.a.j.oak.plugins.segment.Journal
13 matches
Mail list logo
