Re: [OSSTEST PATCH 1/2] Executive DB: Eliminate SQL locking for read-only transactions

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-12-11 at 16:23 +0000, Ian Jackson wrote:
> Our transactions generally run with
>   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> (which, incidentally, does not mean that the transactions are
> necessarily serialisable!)
> 
> In SQL in general it is possible for a read-only transaction to fail
> and need to be retried because some writer has updated things.
> 
> However, in PostgreSQL this is not possible because Postgres uses
> multi-version concurrency control: it retains the old version of the
> data while the read transaction is open:
>   http://www.postgresql.org/docs/8.3/static/transaction-iso.html
> 
> (And, of course, SQLite uses MVCC too, and all transactions in SQLite
> are fully serialisable.)
> 
> So it is not necessary for these read-only operations to take out
> locks.  When they do so they can unnecessarily block other important
> work for long periods of time.
> 
> With this change, we go further from the ability to support databases
> other than PostgreSQL and SQLite.  However, such support was very
> distant anyway because of differences in SQL syntax and semantics, our
> reliance in Executive mode on sql's command line utilities, and so on.
> 
> We retain the db_retry framing because (a) although the retry loop is
> not necessary in these cases, the transaction framing is (b) it will
> make it slightly easier to reverse this decision in the future if we
> ever decide to do so (c) it is less code churn.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(I haven't actually checked that everywhere you have changed is actually
r/o, nor whether you have found every r/o operation).


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