[unixODBC-support] FW: can calling SQL_ATTR_CONNECTION_DEAD in SQLGetConnectAttr() result in blocking?

Antony Davies antony.davies at tmx.com
Wed Mar 13 14:36:52 GMT 2013

Hi Nick, I strace'd the  output with and without the SQLGetConnectAttr() call the  there is indeed extra IO (a write and read) on the socket which is connected to the oracle database  due to the SQLGetConnectAttr(), so it can indeed it can block since it requires an ack from the server
to determine the connection status.

Thanks for your help, Antony

From: Nick Gorham [mailto:nick at lurcher.org]
Sent: Tuesday, March 12, 2013 4:56 PM
To: Support for the unixODBC project
Cc: Antony Davies
Subject: Re: [unixODBC-support] can calling SQL_ATTR_CONNECTION_DEAD in SQLGetConnectAttr() result in blocking?

On 12/03/13 19:54, Antony Davies wrote:
Hi, is it possible for the call to block, or just it just return local state?

I have multiple threads on commit txn calls, and one on start transaction call when I
think this blocks (not 100% certain is just based on observations in a log file)

We are using version 2.2.14 of the odbc driver with oracle 10

Description     = Oracle 10g R2 ODBC driver.
Driver          = /app/oracle/product/10gR2/lib/libsqora.so.10.1
Setup           = /usr/lib64/liboraodbcS.so
FileUsage       =
CPTimeout       =
CPReuse         =


No way of me knowing without knowing what the driver does with that call.

Maybe try running under strace/truss/dtrace and seeing what happens after the call.


NOTICE OF CONFIDENTIALITY This e-mail, including all materials contained in or attached to this e-mail, contains proprietary and confidential information solely for the internal use of the intended recipient. If you have received this email in error, please notify us immediately by return e-mail or otherwise and ensure that it is permanently deleted from your systems, and do not print, copy, distribute or read its contents.

AVIS DE CONFIDENTIALIT? Le pr?sent courriel, y compris tous les documents qu'il contient ou qui y sont joints, renferme des renseignements exclusifs et confidentiels destin?s uniquement ? l'usage interne du destinataire pr?vu. Si vous avez re?u le pr?sent courriel par erreur, veuillez nous aviser imm?diatement, notamment par retour de courriel, et vous assurer qu'il est supprim? de fa?on permanente de vos syst?mes; veuillez ?galement vous abstenir d'imprimer, de copier, de distribuer ou de lire son contenu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20130313/67d6c87c/attachment.html>

More information about the unixODBC-support mailing list