Threading problems at program exit

[maney at pobox.com]

Dave Cole <djc at object-craft.com.au> wrote:
> Now the problem is that even though the database connection can be
> shared between threads it can only support a single query in flight at
> a time.  This means that while a cursor is fetching results over a
> Connection I need the Cursor to maintain a lock on the Connection.  I
> do not have any control over the structure of the client code which is
> using the Cursor.

Another possible solution, which I believe I have heard in a
description of (I believe) one of the PostgreSQL adapter
implementations, might be to create multiple connections behind the
scenes, and hold them as a managed resource.  (of course this includes
caching the arguments needed to open a new connection.) There would not
be a fixed, one-to-one connection between Connection objects and
connections, as well as less easily described complications in managing
the relations between Cursor objects and actual connections.  It sounds
messy, but that may be necessary when the semantics of the actual
connection don't match up very well with the abstraction's goals.

> In my code the Cursor obtains a lock on the Connection at the start of
> a result set and releases the lock at the end of the result.  This has

So the locking implementation can go belly up whether the arguing
cursors are in one thread or two - all that's required is that one
Cursor be "abandonded" without completing the underlying transaction. 
No?  This seems to be a problem quite independent of threads.