On 06/05/2014 20:29, Michael Dürig wrote:
> On 6.5.14 2:59 , Davide Giannella wrote:
>> On 02/05/2014 10:38, Michael Dürig wrote:
>>> Stay with the linked list / skip list approach but defer inserting new
>>> keys to a background operation. Instead new keys are put into a
>>> "pending-non-conflicti
On 6.5.14 2:59 , Davide Giannella wrote:
On 02/05/2014 10:38, Michael Dürig wrote:
Stay with the linked list / skip list approach but defer inserting new
keys to a background operation. Instead new keys are put into a
"pending-non-conflicting-id" container until picked up by a background
threa
On 02/05/2014 10:38, Michael Dürig wrote:
> Stay with the linked list / skip list approach but defer inserting new
> keys to a background operation. Instead new keys are put into a
> "pending-non-conflicting-id" container until picked up by a background
> thread and merged into the linked list. Con
On 30.4.14 9:41 , Davide Giannella wrote:
On 29/04/2014 16:06, Davide Giannella wrote:
...
Serving searches could be done either by the `:next` stream or by the
`:next` and then merged on the fly with the current `:next-ID` in the
iterator while returning the resultset.
Any thoughts on the a
On 29/04/2014 16:06, Davide Giannella wrote:
> ...
>
> Serving searches could be done either by the `:next` stream or by the
> `:next` and then merged on the fly with the current `:next-ID` in the
> iterator while returning the resultset.
>
> Any thoughts on the above?
More thinking around it... if
On 29/04/2014 14:27, Michael Dürig wrote:
> Hi Davide,
>
> Sounds like an interesting idea. In fact, Tom and me discussed
> something very similar during lunch.
>
> In case of a "conflict" there would be multiple :next-xxx properties.
> When the index is used and those are traversed, the "right" :n
Hi Davide,
Sounds like an interesting idea. In fact, Tom and me discussed
something very similar during lunch.
In case of a "conflict" there would be multiple :next-xxx properties.
When the index is used and those are traversed, the "right" :next-xxx
property would need to be followed. At the sam
Thank you all for the support and feedbacks.
In the aim of find a structure that avoid conflicts I was thinking is to
generate a "cluster-node-unique" :next
property. Something like
:next-System.nanoTime()-new Random(System.nanoTime()).nextLong()
by the fact that we're going to generate this
Hi,
On Mon, Apr 28, 2014 at 9:43 AM, Davide Giannella
wrote:
> On 23/04/2014 15:05, Michael Dürig wrote:
>> On the SegmentNS there is still a potential for conflicts between
>> sessions. So we'd need some conflict validation there too.
> Just for records. Worked a couple of days with Michael tryi
On 23/04/2014 15:05, Michael Dürig wrote:
> On 23.4.14 3:34 , Davide Giannella wrote:
>> On 23/04/2014 13:59, Michael Dürig wrote:
>>>
>>> Hi Davide,
>>>
>>> While this looks attractive at first I think there are several
>>> problematic aspects:
>>>
>>> 1. We need different implementations for this
On 23.4.14 3:34 , Davide Giannella wrote:
On 23/04/2014 13:59, Michael Dürig wrote:
Hi Davide,
While this looks attractive at first I think there are several
problematic aspects:
1. We need different implementations for this index depending on
whether SegmentNS or DocumentNS is being used.
On 23/04/2014 13:59, Michael Dürig wrote:
>
> Hi Davide,
>
> While this looks attractive at first I think there are several
> problematic aspects:
>
> 1. We need different implementations for this index depending on
> whether SegmentNS or DocumentNS is being used.
Yes that would be the case. For Se
Hi Davide,
While this looks attractive at first I think there are several
problematic aspects:
1. We need different implementations for this index depending on whether
SegmentNS or DocumentNS is being used.
2. The lexicographically order of the DocumentNS must coincide with
Java's String.
Good evening everyone,
(long email warning)
had an offline discussion with Marcel regarding OAK-1717.
Even by having annotating conflicts for the DocumentNS persistence by
implementing OAK-1185 could not suffice for some cases.
https://issues.apache.org/jira/browse/OAK-1717
https://issues.apach
14 matches
Mail list logo
