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/ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
