Threading problems at program exit

[Dave Cole]

>>>>> "maney" == maney  <maney at pobox.com> writes:

maney> 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.

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

That is an interesting approach.  I should have a look at the
PostgreSQL adapter to see how intrusive the approach is.

>> 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

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

True.

Anyone developing a multi-threaded application has to be aware of the
possible deadlock situations.  Having said that I suppose I should be
going out of my way to introduce more opportunities for deadlock :-)

- Dave

-- 
http://www.object-craft.com.au