gnclock table remains after quitting gnucash and shutdown; Only clears manually with sqlite3

[GWB]

I have been using the sqlite3 backend for GnuCash for well over a year
now and as of last week GnuCash has been reporting the "file locked"
error on opening.  I was able to clear the lock by using sqldiff to
compare a locked and unlocked file.  To unlock the file from the
command line:

% sqlite3 database-name.gnucash
sqlite> DELETE FROM gnclock WHERE rowid=1;
sqlite> .exit

Then the file opens without the lock error, but after closing GnuCash,
shutting down, and opening the file again, it locks and I have to
repeat the process.

The only documentation I can find is here:

http://wiki.gnucash.org/wiki/SQL

So I assume that sqlite3, postgresql and MySQL follow the same
procedure, which is to create the gnclock table to prevent concurrent
access.

Any ideas how to solve this without resorting to the sqlite3 command
line?  Here are the specs for my machine:

% uname -a
... 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux

% gnucash --version
GnuCash 2.6.1
This copy was built from rev 76cba80+ on 2014-02-19.

The file system for the binary is btrfs, and ext4 for the home
directory and data:

% mount
...
/dev/sdc3 on / type btrfs (rw,ssd,subvol=@)
...
/dev/sdb3 on /home2 type ext4 (rw)

The database back end is:

libdbd-sqlite3 version 0.9.0-2ubuntu2

Would the other libdbd back ends work (i.e., libdbd-mysql,
libdbd-pgsql)?  Do users with these other back end dbd's see this
error?

I can check and see if the file systems have acl's and xattr's
enabled, but I don't see how that would affect the database file
itself.

Thanks,

Gordon