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 <[EMAIL PROTECTED]> 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/ -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
