jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] Index on randomly distributed data
Date Tue, 06 Mar 2012 16:39:57 GMT
Hi,

> I suggest that we define a set of relevant
> performance benchmarks, and  use them for
> evaluating potential alternatives.

Sounds good to me.


This thread isn't about UUIDs, I'm sorry if this was not clear. By the
way, a UUID doesn't have to be randomly distributed. For example Microsoft
introduced sequential UUIDs in SQL Server 2005 -
http://msdn.microsoft.com/en-us/library/ms189786.aspx - Other libraries /
products support this as well. We could also use such sequential UUIDs in
Jackrabbit (2 or 3) for the jcr:uuid property.

Regards,
Thomas



On 3/6/12 5:01 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>This thread is confusing two different things: the UUID accessible as
>the jcr:uuid property of a JCR node, and the internal reference used
>by the underlying storage implementation to locate a specific node
>state. In Jackrabbit 2.x these are the same, but in jr3/oak this is no
>longer the case since the MVCC model implies that the internal storage
>references change at each content change.
>
>IIUC Thomas' original post was about the latter case, i.e. the
>internal storage references, *not* jcr:uuid properties.
>
>The tree interface we've been drafting in the other thread explicitly
>hides the underlying storage identifiers, which should help isolate
>this design decision from higher levels of code.
>
>Rather than discuss this issue in the abstract, I suggest that we
>define a set of relevant performance benchmarks, and  use them for
>evaluating potential alternatives.
>
>BR,
>
>Jukka Zitting


Mime
View raw message