Multithreaded ODBC SP call locking problem

Matthew Gates <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <84F1FFCF43457A4B89A4ED49C998C4E2FBBA9243@redofmail01.office.redeu.local>
I'm looking at a problem talking to MS-SQL. My program holds open several (typically 4) connections to the database.  Each connection is managed by a thread in the app, which queues and sends requests to execute a stored procedure.

The SP is the same every time, and there is no data-driven conditional logic, just the following sequence of ODBC calls:  SQLAllocHandle; SQLBindCol; SQLBindCol; SQLFetch; SQLCloseCursor; SQLFreeHandle; SQLEndTran.

This works for ages (10s or 100s of thousands of times), but very occasionally the SP finishes but does not commit open transactions.  We can see SQL Server sending the output parameter over the network, so we're sure the SP is complete, but the program doesn't seem to send back the SQLEndTran request.  The result is locks in the database which cause other problems.

Searching through the archives I found this post: http://lists.ibiblio.org/pipermail/freetds/2009q4/025439.html

...which mentions UnixODBC threading and a known problem.

So finally my question: I was wondering what the referenced problem is and if it might cause the problem I'm looking at?  Also, if anyone has any ideas as to what I might look at, I would be very interested to hear them.

freetds-0.62.4  (I know, I'm sorry, it's very old.  Not my choice!)
unixODBC-2.2.11

P.S. Greetings FreeTDS mailing list!  My first post.




Disclaimer

This email transmission is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, distribute or disseminate the information, or take any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of any organisation or employer. If you have received this message in error, do not open any attachment but please notify the sender (above) deleting this message from your system.
______________________________________________________________
This message has been scanned for all viruses by BTnet VirusScreen.
The service is delivered in partnership with MessageLabs.

This service does not scan any password protected or encrypted
attachments.

Retail Decisions Ltd.; Registered Office: ReD House, Brookwood, Surrey GU24 0BL; Company Number: 3885583
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.