I basically do this too in a multi-tier setup (1 write, n read, also some loggers). Everything in my /account section is handled by the Master (read/write), everything else is read only off slaves.
The initial engine setup is nothing. The biggest hit is the metadata, and that can be recycled across engines. You definitely want/need multiple sessions. Just consider them to be different databases. I have some bad (but usable) code for Pyramid that is on github. I need to rewrite it, but it works. I can point you at it if you'd like. I went though a lot of the (premature) optimization steps, and then had a revelation when doing some postgres debugging once -- Michael optimized SqlAlchemy so incredibly well, that my code could be really sloppy and it wouldn't matter. The sessions/sessionmaker have almost no overhead until you use them for database operations, and the overhead it ridiculously small. They don't even connect to the database until you use them for an operation that 'emits sql'. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
