By all means a per thread connection pool sounds like a much more sane approach. check_same_thread may not be safe but it does work so far for my use case and I agree it should not be enabled by default.
~GvZ On Jan 15, 2008 4:53 PM, Richard Boulton <[EMAIL PROTECTED]> wrote: > > Are you sure this is safe to do? As I understand it, it is often not > safe to use SQLite objects in different threads than the thread they > were created in, even if you ensure that they are not accessed > concurrently. The option not to check is simply a way of reducing the > overhead in the case where you are sure that access is being done safely. > > This is certainly what the pysqlite documentation implies: > > **check_same_thread** - SQLite connections/cursors can only safely be > used in the same thread they were created in. pysqlite checks for > this each time it would do a call to the SQLite engine. If you are > confident that you are ensuring safety otherwise, you can disable > that checks by setting check_same_thread to False. > > Also see http://sqlite.org/faq.html#q6 - the problems involve > limitations of fcntl, and it is safe to move connections between threads > in only certain circumstances (SQLite version at least 3.3.1, > compiled with SQLITE_THREADSAFE = 1, and no fcntl locks are currently > held by the connection). If you're going to allow this in storm, you > should probably be checking that these constraints are met at the storm > level before you allow the threads to be moved, rather than just turning > off the check and hoping. > > It's probably safer just to use a separate pool of connections for each > thread (using thread local storage, probably). > > -- > Richard > -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
