On 23.7.13 12:26, Chetan Mehrotra wrote:
In discussion referred to in OAK-775 it was mentioned that the event
processing would be pluggable. Is that still the case? If we make the
merge method synchronized then it cannot be avoided through a
different PostCommitHook implementation
No, not plu
> https://issues.apache.org/jira/browse/OAK-775). The compromise we came
> up with in OAK-775 is to maintain such information for local events
> (i.e. b1->h1 for node A and b1->h2 for node B), but not for events
> originating from the rest of the cluster (i.e. h1->h3 and h2->h3).
Okie now I unders
Hi,
On Tue, Jul 23, 2013 at 12:47 PM, Chetan Mehrotra
wrote:
>> The end result in either case is a sequence of events from b1 to h3.
>
> If this is fine (and something which cannot be avoided) then cannot we
In general that can't be avoided in a fully distributed case.
> just make the NodeState
Hi Michael,
On Tue, Jul 23, 2013 at 2:59 PM, Michael Dürig wrote:
> It is still possible to have two not branches merging against the same base
> revision. I.e. two branches that are not rebased on top of the current trunk
> and "merge internally". IFAICS it is also necessary for
> NodeStoreBranc
> The end result in either case is a sequence of events from b1 to h3.
If this is fine (and something which cannot be avoided) then cannot we
just make the NodeState comparable and avoid synchronizing the merge?
As that still allows us to see an ordered flow of changes.
Chetan Mehrotra
On Tue,
On 23.7.13 10:57, Chetan Mehrotra wrote:
Its possible that for a series of changes like [b1,h1] ->[ b1,h2] ->
[h1,h3] the observation logic miss out seeing in between state
transition. But it would effectively see all the changes. Only changes
which get negated between missed transition would n
On 22.7.13 13:14, Michael Dürig wrote:
- explicitly synchronise in the case of the MircorKernel based
implementations.
As Chetan mentions in the other mail, synchronisation alone does not
help here. It is still possible to have two not branches merging against
the same base revision. I.e. t
Hi,
On Tue, Jul 23, 2013 at 11:57 AM, Chetan Mehrotra
wrote:
> How this would work in a cluster mode. If two nodes in a cluster
> perform commit with (base revision, head revision) [b1,h1] and [b1,h2]
> then how would observation work?.
Assuming h3 is the result of merging h1 and h2, then:
* No
>> The limitation would be on the set of concurrent
>> sessions for which we want to keep track of local commit information
>> for observation.
How this would work in a cluster mode. If two nodes in a cluster
perform commit with (base revision, head revision) [b1,h1] and [b1,h2]
then how would obs
On 22.7.13 12:48, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jul 22, 2013 at 1:35 PM, Michael Dürig wrote:
>> For other NodeStore implementations I currently don't see how to reuse the
>> code from SegmentMK without changing the contract of the Microkernel.merge
>> method. As long as that method does
On 22.7.13 12:48, Jukka Zitting wrote:
Hi,
On Mon, Jul 22, 2013 at 1:35 PM, Michael Dürig wrote:
For other NodeStore implementations I currently don't see how to reuse the
code from SegmentMK without changing the contract of the Microkernel.merge
method. As long as that method does its own m
Hi,
On Mon, Jul 22, 2013 at 1:35 PM, Michael Dürig wrote:
> For other NodeStore implementations I currently don't see how to reuse the
> code from SegmentMK without changing the contract of the Microkernel.merge
> method. As long as that method does its own merge magic we need to prevent
> concur
On 22.7.13 12:05, Jukka Zitting wrote:
Hi,
On Fri, Jul 19, 2013 at 7:00 PM, Michael Dürig wrote:
Chetan discovered that in some cases spurious observation events would be
created when to sessions save concurrently. In a nutshell the problem occurs
since the current implementation of observat
Hi,
On Fri, Jul 19, 2013 at 7:00 PM, Michael Dürig wrote:
> Chetan discovered that in some cases spurious observation events would be
> created when to sessions save concurrently. In a nutshell the problem occurs
> since the current implementation of observation [1] expects a linear
> sequence of
Hi,
Chetan discovered that in some cases spurious observation events would
be created when to sessions save concurrently. In a nutshell the problem
occurs since the current implementation of observation [1] expects a
linear sequence of revisions (per cluster node). However on Root.commit
the
15 matches
Mail list logo
