------_=_NextPart_001_01C6A4CD.D35FB632
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello,
We are using OTL 4.0 to access a mysql database. From the documentation,
it seems that the otl library is not threadsafe. In our application, we
have two threads accessing the otl_connect object and we were seeing
crashes while running load test. Following is the backtrace from gdb:
(gdb) bt
#0 0x008f5353 in list_add () from /usr/lib/libmyodbc3-3.51.11.so
#1 0x008e107a in my_SQLAllocStmt () from /usr/lib/libmyodbc3-3.51.11.so
#2 0x008e14cf in SQLAllocHandle () from /usr/lib/libmyodbc3-3.51.11.so
#3 0x00832143 in otl_cur::open (this=3D0xb7239808, =
connect=3D [at] 0x82eda14) at
otlv4.h:9161
#4 0x008319b1 in otl_tmpl_cursor<otl_exc, otl_conn, otl_cur,
otl_var>::open (this=3D0xb72397f8, connect=3D [at] 0x82eda0c, var=3D0x0) at
otlv4.h:3536
#5 0x0082f927 in otl_tmpl_cursor (this=3D0xb72397f8, =
connect=3D [at] 0x82eda0c)
at otlv4.h:3494
#6 0x0082a758 in otl_tmpl_select_cursor (this=3D0xb72397f8,
pdb=3D [at] 0x82eda0c, arr_size=3D50, sqlstm_label=3D0x0) at otlv4.h:4559
#7 0x00828038 in otl_tmpl_select_stream (this=3D0xb72397f8,
aoverride=3D0xb7237a14, arr_size=3D50,
sqlstm=3D0xb72582c8 "SELECT PublicUserIdentityIndex FROM
PublicUserIdentity WHERE PublicUserId=3D\"2212436166\";", =
pdb=3D [at] 0x82eda0c,
implicit_select=3D0,
sqlstm_label=3D0x0) at otlv4.h:4750
#8 0x00825e4a in otl_stream::open (this=3D0x4573900, arr_size=3D50,
sqlstm=3D0xb72582c8 "SELECT PublicUserIdentityIndex FROM
PublicUserIdentity WHERE PublicUserId=3D\"2212436166\";", =
db=3D [at] 0x82eda0c,
implicit_select=3D0,
sqlstm_label=3D0x0) at otlv4.h:11147
#9 0x00249671 in SmaGetPublicIndex::prepare (this=3D0x4574700,
publicId=3D0xb7256444 "2212436166", publicIdx=3D0x457473c) at
SmaGetPublicIndex.cpp:89 #10 0x008015d8 in
DaSubsMgrTask::handleDaapiGetAuthDataRpy (this=3D0x82ed738,
daapi=3D0xb72563c8, context=3D0x83c4830) at DaSubsMgrTask.cpp:461
We changed the code to instantiate two otl_connect objects (with the
same connect params) and now have each thread accessing the database
through its dedicated otl_connect object. However, we are still seeing
the same core. From the backtrace, we noticed that the connect pointer
(highlighted in red above) has moved by a byte?
Any pointers on the above will be very helpful. I had queried the author
of OTL (Sergei Kuchin) and he seems to believe that this may be an issue
with ODBC.
Thanks,
Aniket
------_=_NextPart_001_01C6A4CD.D35FB632--
