[storm] Threading question

[Gerdus van Zyl]

Read on the SQLite website that since version 3.5.0: The same database
connection may now be used simultaneously by separate threads.

On Jan 15, 2008 5:34 PM, Gerdus van Zyl <gerdusvanzyl at gmail.com> wrote:
> 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 <richard at lemurconsulting.com> 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
> >
>