I did manage to screw up locking in parallel testing after all

We try to grab a new engine lock within the same test before releasing
the one for the previous engine

diff --git a/t/lib/DBICTest/Schema.pm b/t/lib/DBICTest/Schema.pm
index b77c0d7..9ae6632 100644 (file)
--- a/t/lib/DBICTest/Schema.pm
+++ b/t/lib/DBICTest/Schema.pm
@@ -74,7 +74,7 @@ our $locker;
 END {
   # we need the $locker to be referenced here for delayed destruction
   if ($locker->{lock_name} and ($ENV{DBICTEST_LOCK_HOLDER}||0) == $$) {
-    #warn "$$ $0 $locktype LOCK RELEASED";
+    #warn "$$ $0 $locker->{type} LOCK RELEASED";
   }
 }
 
@@ -150,6 +150,10 @@ sub connection {
     # Also if there is no connection - there is no lock to be had
     if ($locktype and (!$locker or $locker->{type} ne $locktype)) {
 
+      # this will release whatever lock we may currently be holding
+      # which is fine since the type does not match as checked above
+      undef $locker;
+
       my $lockpath = DBICTest::RunMode->tmpdir->file(".dbictest_$locktype.lock");
 
       #warn "$$ $0 $locktype GRABBING LOCK";