[elephant-devel] How should I handle a controller-lost-error?

Alain Picard Dr.Alain.Picard at gmail.com
Mon Oct 5 11:38:49 UTC 2009


Ian Eslick <eslick at media.mit.edu> writes:

> There was a bug with the get-con function that returns nil after the  
> restart.  I just checked in a fix for that and went ahead and  
> implemented your suggestion for a saner error + restart model.  

That's great.  I'll do a checkout and start playing with that
tomorrow.

> For the web responding function you describe, with-transaction will  
> handle most cases of error as it aborts a transaction on an error and  
> the web page should respond with a 500 error.   If the store has  
> closed, this is basically a global and probably catastrophic server- 
> level rather than request-level problem.  

OK - that's the sort of info I was after  --- i.e. that the
store getting closed "behind your back" is a very serious, "can't
happen" type of error.  Something to do with deleting libdb.so
while the application runs, or the disk filling up, or something
equally severe.  So if I ever catch something like that, it's time
to stop the application, raise a loud alarm somewhere, and wait for
a human to fix things up.

> Frankly the code paths that are exercised when *store-controller* is  
> nil or a store is closed have not been heavily used or terribly well  
> thought through.  All the usage models for Elephant that I'm aware of  
> have been single-store settings where *store-controller* is bound once  
> globally.

Great!  That's what I was hoping to get away with.  so, START-APP
opens the store; sets *store-controller* globally, and everone
just uses WITH-TRANSACTION to isolate threads against each other.
And you get excellent performance, as a side benefit.

> Is this helpful?

Incredibly so.  Thank you very much for your time.

One last question, while I have your attention: I think I intend
to have more than 1 process on the machine access the store
concurrently; but I assume that's no more dangerous than having
multiple threads doing so; and Berkeley DB should be able to
take care of itself and protect the integrity of the store against
multiple simultaneous writers.  I may have to set some magic
locking flags when opening the environment, but that should be
about it.  Is that your understanding also?

Anybody else do this?  Anyone seen any mysterious crashes?  

I greatly (greatly!) appreciate your answers, not to mention
the wonderful elephant package.  It feels a lot more solid than
when I last looked at it a couple of years ago.  Thanks!

       --Alain





More information about the elephant-devel mailing list