On 8 May 2012 19:38, Robert Collins <...> wrote: > In addition to Clint's excellent points (all of which I agree with), > I'd also add two more points: > > * pserv, being twisted, means that it will have a hate-hate > relationship with ORM state, just keeping it from doing silly things > like keeping a transaction open for days will be an exercise in > great care and diligence.
PostgreSQL can enforce transaction and/or query time-outs, can't it? If not, then Twisted has callLater. > > * all the protections we (eventually) put in place around the DB > (such as timeouts and worker concurrency limits) will have to be > replicated for pserv, and as it has a different programming model, > that means double work. In LP we haven't done this yet, and we have > had the failure modes (like a script that goes nutty keeping backps > from running, or a concurrent script causing unanticipated load) at > one time or another. MAAS, being deployed on customer sites, outside > of our ops teams reach, has to insulate itself from these sorts of > things. We used Storm and transactions and all that stuff with ease and without incident in clouddeck with no special provisions for Twisted other than: do transactional stuff in a thread that is not the reactor thread [1]. I'm almost certain that it would be trivial to use Django's ORM within Twisted too. [1] Or: *never ever ever never ever* do transactions in the reactor thread. Partly because, iirc, the transaction module expects to be able to use thread-locals to keep track of transaction state, hence doing all transactions in a single thread leads us right into the belly of the beast. -- Mailing list: https://launchpad.net/~maas-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~maas-devel More help : https://help.launchpad.net/ListHelp
