On Saturday 16 February 2008, Oleg Broytmann wrote:
> On Sat, Feb 16, 2008 at 03:53:19PM +0200, Neil Muller wrote:
> > I've added a quick patch to do this, based of the logic in
> > sqliteconnection, to the sourceforge issue tracker (# 1894909), which
> > fixes the issue for me.
> Thank you!
> I would very much like to ask people to review and test the patch.
I do not like this approach. The limitation only says that one cannot use
a connection from multiple threads at the same time, not that you cannot
create a connection in one thread and then use it in another, as long as
you make sure the connection is not operated on at the same time from
different threads. As the patch works (and this is the case with sqlite
as well), one cannot create the connection in any other thread than the
one that it is used in, which is a very severe limitation. I always found
this behavior of the sqlite backend annoying as it imposes unnecessary
restrictions over the others backends.
There are cases where you create the connections in the main thread and
then use them later in a db dedicated thread. I do this in my
applications and I have no issues at all with threading.
Another aspect that will have to suffer from this change is that if you
have a specialized connection pool that only creates a limited number of
connections (say 3) which you want to share between 10 threads, it will
no longer work, because with the patch the pools are per thread. With the
way it is now, you can take a connection from the pool in one thread, use
it and when you're done with it put it back in the pool to be used by
another thread. With the patch that will not be possible anymore and
restricting the number of connections one applications makes to a
database will no longer be possible if there are multiple threads
I do not believe that putting such restrictions in a generic module like
sqlobject, for the sole reason of preventing users who do not know how to
write safe multithreading code from shooting themselves in the foot, is
the proper approach for solving this issue. I expect that if someone
writes multithreaded applications, then he knows how to write them and
how to protect access to shared resources.
If I'm for a change, then I'm for removing this limitation from sqlite as
well rather than putting it in other backends too. In the end I think
that people took that "non-shareable" warning way to strictly. It doesn't
say that you cannot use it in different threads, only that you cannot use
it in different threads _at the same time_ which should be common
knowledge. In the end a db connection boils down to a file descriptor (be
that a socket or a file) over which data is transfered. Anyone should be
aware that you cannot do safe operations over a file descriptor from
multiple threads if they read/write at the same time. Yet, I do not see
the file() (from core) or socket() (from the socket module) functions
imposing such a limitation that you cannot create the file descriptor or
socket in any other thread than the one you use it in.