[storm] Pooling ?

[Christopher Armstrong]

Stepping in to give some perspective from a Storm developer who
doesn't use CherryPy...

On Nov 20, 2007 11:35 AM, Håvard Gulldahl <havard at lurtgjort.no> wrote:
> 1)
> In the example you're commiting after a store.find() -- is that just for
> the sake of argument?
>
> More generally, why are you store.commit()-ing on every request? Since
> the store is local to the thread, wouldn't getting stuff from the storm
> cache (that commit() invalidates) be more convenient?

I'm not really sure I fully understand your question, but in most
cases committing on every request (generally, aligning the concepts of
transaction and request so you have one transaction per request) is
the best way to write a web app.

Perhaps I'm misunderstanding, and you're just suggesting an
optimization to avoid commiting if no changes have been made? You'd
still need to rollback() to see changes from other transactions
(assuming you're using SERIALIZABLE transaction mode, which you ought
to be). In any case, commiting when there are no changes is very fast.

> 2)
> How do you handle disconnects?

Database disconnects are going to be handled gracefully by Storm
itself in the upcoming release.

> 2.1)
> Previously, one of the cherrypy devs (fumanchu) stated that[1] in
> certain circumstances, there is no clean way to detect and disconnect
> when a thread ends, and made the case for per-request database
> connections. Has this changed?

In the worst case, Python's garbage collector will kick in and kill
the Store object, which closes the connection to the database.


-- 
Christopher Armstrong
International Man of Twistery
http://radix.twistedmatrix.com/
http://twistedmatrix.com/
http://canonical.com/