incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: Thoughts on Transactions, Concurrency, Versioning and Locking
Date Mon, 27 Sep 2010 16:28:25 GMT
On Mon, Sep 27, 2010 at 11:01 AM, Danny Ayers <> wrote:

> On 27 September 2010 09:56, Reto Bachmann-Gmuer <> wrote:
> Just thought on this:
> > *Performance*
> > On read access apart from the base-graph a set of patches has to be
> checked,
> > both for additions and removals of triples. As under normal circumstances
> > the umber of patches should be relatively small this shouldn't be too
> bad.
> > Write operations should get significantly faster as generating and adding
> a
> > patch does not require a qrite lock on the base graph.
> Seems the kind of place it might be useful for there to be flags that
> can be set for reading:
> 1 : state without any pending patches - fast but possibly stale
> 2 : state including patches from transactions in progress - fast but
> possibly inconsistent (client assumes "eventually consistent")
> 3 : state with all queued patches - slower but up-to-date & consistent
1: I thought of the separation patches/base graph to be invisible from
outside but if it turns out to be a frequent wish to access a faster but
less up-to-date version of the mgraph we can surely implement this.
2: Do you see a concrete usecase for this? I think we should have very good
reasons to break encapsulation of transaction, generally I would prefer to
guarantee that before successful no change of the transaction is visible
3: This should be the default state and I think that with most systems there
shouldn't be to many pending patches, to support systems with very heavy
read access we could supports clusters so that while one instance in the
cluster applies patches to the base mgraph the other system can still handle


> No idea what this might look like in implementation.
> Cheers,
> Danny.
> --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message