On Nov 9, 2011, at 11:42 AM, Matthew Newville wrote: > First, I apologize in advance for the vague question and thank you in advance > for the great SQLAlchemy library, and any help you might be able to give. I > have a GUI application (wxPython) that uses SQLAlchemy and sqlite3 to store > state information. The application connects to network resources, using a > wrapped C library that internally makes heavy use of threads. > > This application worked (and still works) fine with sqlalchemy 0.6.8, but > gives "database is locked" errors on "session.commit()" with 0.7.2 and 0.7.3. > I get the same behavior on both linux (python 2.6) and windows (python 2.6 > and 2.7). > > This app definitely needs to communicate with the network resources, and the > interaction with that library needs to be wrapped with wx.CallAfter() in > order to isolate network communication from the GUI threads. I've tried to > be careful about separating this from calls to sqlalchemy/sqlite, and am not > finding any obvious errors. > > Are there any ideas about what changed between 0.6.8 and 0.7.2 that might > trigger this change? Are there any general suggestions on how to resolve > this? It seems the previous questions about "database is locked" are > answered with "don't use sqlite". This application really needs a single, > no-server datastore, so that would mean either staying with 0.6.8 > indefinitely or not using SQLAlchemy, neither of which seems like a good > choice to me.
Yes, the default pool implementation for a file-based database changes to NullPool in 0.7 - such that each call to connect() on an engine returns a brand new SQLite connection. Not sure why this leads to "database is locked" issues though whereas you didn't have them earlier - ideally you should ensure things are using a single connection all the way through within a given thread. You can pass pool_threadlocal=True to create_engine() which will cause the NullPool to return the same connection for all calls to connect() or execute() within a given thread and would act pretty much like the defaults in 0.6 - or you could use SingletonThreadPool specifically which is what 0.6 used. > > Again, thanks for any insight. > > --Matt > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sqlalchemy/-/T3WBK-ZU6fIJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
