Hi 一首诗, what database engine are you using? On PostgreSQL at least, table creation and dropping (and some other operations) take an ACCESS EXCLUSIVE lock on the database, and will wait for this lock indefinitely if there are open transactions hanging around. My app creates and drops tables willy-nilly, not just at start-up, and I find that I have to be very careful about session lifetimes. So I gave up scoped_session entirely.
Note that you don't need to avoid creating sessions again and again (not to save on performance anyway), see http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-questions "Sessions are very inexpensive to make, and don't use any resources whatsoever until they are first used...so create some!" In particular, note that a session is distinct from a database connection -- database connections are (typically) expensive to create, and SQLAlchemy handles connection pooling to save on those costs. That's probably what you were intending, and it happens even if you keep making new sessions. Regards, - Gulli On Mar 4, 11:26 am, 一首诗 <newpt...@gmail.com> wrote: > Hi, all > > I am using sqlalchemy in twisted in my project in the way below. > Defer any database operation so the twisted's main thread won't be > blocked. > > And I use scoped_session, so that sessions won't have to be created > again and again. > > ====================================== > class Database() > def __init__(self, conn_str): > self.conn_str = conn_str > self.engine = create_engine(self.conn_str, echo=False) > self.Session = scoped_session(sessionmaker(bind = self.engine, > expire_on_commit=False)) > > def getObjectById(self, klass, id): > return threads.deferToThread(self._getObjectById, klass, id) > > def _getObjectById(self, klass, id): > sess = self.Session() > return sess.query(klass).get(id) > ====================================== > > The code doesn't work. When I limit the thread numbers to 1 > > reactor.suggestThreadPoolSize(1) > > Everything goes fine. Other wise the server would be blocked and must > be killed by "kill 9 ...". > > The result conflicts with my understanding of sqlalchemy. Since I > don't share any object between threads, there should be no problem! > > Ah.... It always have risk to use something you haven't tried > before .... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
