Hmmm...I believe that only the first to connect should attempt recovery.
Much of these issues are BDB restrictions that one has to live with if
you want to do more than the basic thing with them. It would be
worthwhile for you to read up on BDB if you want to do the multi-
process implementation. I don't know of anyone who has fully charted
this territory and elephant certainly doesn't have specific features
to help you deal (although you can launch a background db_deadlock
process to free deadlocked threads/processes with an argument to open-
store on your master process).
Using the described patch I was able to have two writers, one from an
Allegro image and one from an SBCL image both hammering (reading/
writing) on the same set of objects similar to your example.
By mess up the other process I assume you are running into a crash of
some kind and not data corruption (i.e. transaction design) issues
Ian
PS - Make sure you force a rebuild anytime you update. I've found
asdf doesn't always get it right.
On Feb 26, 2008, at 1:42 PM, Leslie P. Polzer wrote:
I just pushed a patch that should automatically manage two processes
connecting to the same environment. You typically have to coordinate
who is the master user and who is the slave so that you don't try to
recover an environment that is already in use by another process.
This causes that first process to fail, I believe, because it
discovers it's pointers into the environment are 'corrupted'.
Doesn't do it for me. Opening two stores is fine, and I believe even
reading. But writing messes the other process up.
Without attempting recovery, everything seems to be fine.
I must live with that for now, since I ran out of backend choices...
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
