You can run a thread which aborts threads that otherwise would have
hung.
"The DB_ENV->failchk method can now abort transactions for threads,
which have failed while blocked on a concurrency lock. This
significantly decreases the need for database environment recovery
after thread of control failure. [#15626]"
My understanding is that you have to launch a thread to perform these
checks and cause the transactions to abort (this requires true multi-
threading - Allegro for example would not benefit from this since it
still uses a semi-cooperative multitasking to avoid all locking that
has been put into SBCL).
I've made some code changes in elephant-unstable to support 4.7 but
had some bugs getting it running (problems with constants, API
changes) but haven't had the chance to track the errors down. I won't
be doing any more elephant development until at least mid-September.
I am aware that there is a reasonable set of issues with various
lisps, an intermittent de-serializer bug that also shows up in stable,
and a condition that requires restarting the db when I kill stuck
threads that are in the middle of a transaction...
Ian
On Aug 28, 2008, at 10:04 AM, Leslie P. Polzer wrote:
Is it correct that db4.7 has built-in deadlock detection,
and elephant-unstable has been adapted to that?
Leslie
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
