[OSSTEST PATCH 1/2] Executive database: set isolation level in Perl

[OSSTEST PATCH 1/2] Executive database: set isolation level in Perl

[Ian Jackson]

The Perl was lacking SET TRANSACTION ISOLATION LEVEL SERIALIZABLE,
which is sadly not the default.  Currently that does not matter
because of all the table locking, but we are about to abolish that.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 Osstest/JobDB/Executive.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 76f3293..557cee1 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -42,6 +42,9 @@ sub begin_work ($$$) { #method
     my ($jd, $dbh,$tables) = @_;
     
     return if $ENV{'OSSTEST_DEBUG_NOSQLLOCK'};
+
+    $dbh->do("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");
+
     foreach my $tab (@$tables) {
         $dbh->do("LOCK TABLE $tab IN EXCLUSIVE MODE");
     }
-- 
2.1.4


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

[OSSTEST PATCH 2/2] Executive database: stub out use of LOCK TABLES

[Ian Jackson]

We want to improve database performance, and one of the problems is
excessive locking.  Postgresql now has predictate locking, and we
have, we think, eliminated all the places that do not handle a
database transaction failure.  So we can rely on optimistic
concurrency.

So, eliminate all uses of LOCK TABLES.

However, I'm not quite sure that all of the above is actually true -
particularly, with relation to our own error handling.  So, we want to
leave ourselves an escape hatch and an easy reversion path.

The approach adopted is to change the semantics of the transaction
support routines (one in Perl, and one in Tcl) so that the meaning of
all the existing call sites is changed to "do not lock any tables".

But the facility for table locking is retained and any call sites
which still need locking or fixing can use a new parameter format to
say they actually want the locking.

Hopefully this will turn out to be unnecessary.  In that case, in due
course, we can strip out all the locking machinery, abolish all the
corresponding parameters, and so on.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 Osstest/JobDB/Executive.pm | 8 ++++++++
 tcl/JobDB-Executive.tcl    | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 557cee1..c02ff19 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -45,6 +45,14 @@ sub begin_work ($$$) { #method
 
     $dbh->do("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");
 
+    # $tables used to be [qw(some tables)]
+    #  we ignore that for now
+    # callers can pass for $tables [[qw(some tables)]]
+    #  to override this ignorement, in case it causes trouble
+    return unless @$tables && ref $tables->[0];
+    die '[[qw(some tables)], something] ?' unless @$tables == 1;
+    $tables = $tables->[0];
+
     foreach my $tab (@$tables) {
         $dbh->do("LOCK TABLE $tab IN EXCLUSIVE MODE");
     }
diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index 6225bd9..05677e3 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -258,6 +258,8 @@ proc db-execute-array {arrayvar stmt {body {}}} {
 
 proc lock-tables {tables} {
     # must be inside transaction
+    set first [lshift tables]
+    if {[string compare $first REALLY]} return
     foreach tab $tables {
         db-execute "
 		LOCK TABLE $tab IN EXCLUSIVE MODE
-- 
2.1.4


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