[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling



On Fri, Mar 31, 2017 at 03:47:58PM +0200, Juergen Gross wrote:
> On 31/03/17 15:01, Wei Liu wrote:
> > On Fri, Mar 31, 2017 at 02:11:46PM +0200, Juergen Gross wrote:
> >> On 31/03/17 14:03, Wei Liu wrote:
> >>> Another stupid question below.
> >>>
> >>> On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote:
> >>>>  
> >>>> -struct changed_node
> >>>> +/*
> >>>> + * Some notes regarding detection and handling of transaction conflicts:
> >>>> + *
> >>>> + * Basic source of reference is the 'generation' count. Each writing 
> >>>> access
> >>>> + * (either normal write or in a transaction) to the tdb data base will 
> >>>> set
> >>>> + * the node specific generation count to the global generation count.
> >>>> + * For being able to identify a transaction the transaction specific 
> >>>> generation
> >>>> + * count is initialized with the global generation count when starting 
> >>>> the
> >>>> + * transaction.
> >>>> + * Each time the global generation count is copied to either a node or a
> >>>> + * transaction it is incremented. This ensures all nodes and/or 
> >>>> transactions
> >>>> + * are having a unique generation count.
> >>>> + *
> >>>> + * Transaction conflicts are detected by checking the generation count 
> >>>> of all
> >>>> + * nodes read in the transaction to match with the generation count in 
> >>>> the
> >>>> + * global data base at the end of the transaction. Nodes which have been
> >>>> + * modified in the transaction don't have to be checked to match even 
> >>>> if they
> >>>> + * have been read, as the modified node will be globally visible after 
> >>>> the
> >>>> + * succeeded transaction possibly overwriting another modification 
> >>>> which may
> >>>> + * have occurred concurrent to the transaction.
> >>>> + *
> >>>> + * Examples:
> >>>> + * ---------
> >>>> + * The following notation is used:
> >>>> + * I:      initial state
> >>>> + * G       global generation count
> >>>> + * g(X)    generation count of node X
> >>>> + * G(1)    generation count of transaction 1
> >>>> + * g(1:Y)  saved generation count of node Y in transaction 1
> >>>
> >>> Assuming this is recorded in accessed_node, can you point me to where
> >>> about in the code this is implemented? I looked at access_node but that
> >>> only records generation for read.
> >>
> >> It is in the node itself stored in the data base.
> >>
> > 
> > Right, then ...
> > 
> >>>> + * TA1:    operation in transaction 1
> >>>> + * X=1:X   replace global node X with transaction 1 specific value of X
> >>>> + *
> >>>> + * 1. Simple transaction doing: read node A, write node B
> >>>> + *    I: g(A) = 1, g(B) = 2, G = 3
> >>>> + *    Start transaction 1: G(1) = 3, G = 4
> >>>> + *    TA1: read node A:    g(1:A) = 1
> >>>> + *    TA1: write node B:   g(1:B) = 4, G = 5
> >>>
> > 
> > I suggest updating places like g(1:B) = 4 to g(B) = 4 to match the code.
> 
> No, as during the transaction only the node with the transaction
> prepended is being stored in the data base. It isn't visible outside
> the transaction until the transaction has been committed.
> 

Hmm... yes, that's true.

> So the notation isn't reflecting where the generation count is stored,
> but only that it is specific to the transaction/node pair.
> 

OK.

Wei.

> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.