[storm] Threading question

[Gerdus van Zyl]

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
>