Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Dan Pascu <dan <at> ag-projects.com>
Subject: Re: Trouble with threads...
Newsgroups: gmane.comp.python.sqlobject
Date: Saturday 16th February 2008 22:20:54 UTC (over 9 years ago)
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 
involved.

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.

-- 
Dan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
 
CD: 3ms