Christopher Browne <[EMAIL PROTECTED]> writes:
> For this to be useful, this should try to provide some remediation
> measures:
> a) A timestamp would be valuable; if the transaction has been locked
> for 7 hours, this may indicate that something's broken.
You could use an approach where the "locker" has to touch the lock
every so often or lose it. However, although this helps in the case
of a dead process, it's only safe if you have atomic commits and/or if
there's some way to reject the actions of a "locker" that doesn't
touch the lock for a long time (because it's suspended, blocked on NFS
access, or whatever) and then wakes up and tries to act as if it still
holds the lock (because it thinks it does...).
As a related aside, I'd like to favor correctness over sophistication
in any locking strategy we come up with. While there will always be
situations we can't hope to handle (an anvil dropped from 10m onto the
hard-drive for instance), how safe can we make it? Can we make it
safe against process crashes[1]? power outages[2]?
And whatever approach we think of will have to take into account ugly
things like NFS, though I'm happy to just make a restriction like
"Your transaction-logging (or locking) directory *may not* be on an
NFS volume." or even the more draconian "You can't share GnuCash
files over NFS.".
[1] This shouldn't be hard, though it might be expensive.
[2] This might be impossible without help from the filesystem/kernel,
or a good UPS :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
