Hi,

On Wed, Mar 6, 2013 at 3:10 PM, Thomas Mueller <[email protected]> wrote:
> With the current implementation, that's not the case, because revision
> stability with multiple cluster nodes isn't implemented yet. The idea is
> that each cluster node adds revisions of other cluster nodes to its own
> revision list as they are detected.

I see, thanks! So cluster node A could see revisionA coming before
revisionB, while cluster node B might see the opposite, which should
be fine.

Do you have estimates on the potential performance impact of this? It
sounds like especially on a system with high volumes of writes the
revision lists could grow pretty large.

BR,

Jukka Zitting

Reply via email to