Subject | Concurrent API calls into gds32 cause lock |
---|---|
Author | nitaligavino |
Post date | 2002-04-01T15:26:50Z |
I was hopping someone might be able to help with a Firebird issue I'm
having?
Here goes...
Okay, I have a multithreaded client that talks directly to the IB
API, ( using isc_ ... calls, I put a wrapper around this in MS V6
C / C++ )
Thread1 starts and calls isc_attach_database(...) using the connect
string "c:\test.gdb". Thread1 creates a transaction, etc, etc, then
does an INSERT and calls isc_commit_retaining(...). At this point
another thread Thread2 wakes up and tries to connect to the database
using the same string "c:\test.gdb" and the isc_attach_database(...)
call. What happens is the isc_attach_database call locks and never
returns. Meanwhile Thread1 has finished it's work and attempts to
finalize the transaction by calling isc_commit_transaction(...)
however, Thread1 gets locked in the isc_commit_transaction call. Now
both threads are locked and I'm dead.
This is but one of the issues that I have seen but overall it's the
same for all my deadlocks. So I found some information that said
that this can be prevented by using TCP/IP as the connection.
Thus: "localhost:c:/test.gdb". However, I also read that the issue
is in the commit retaining call? Finally, I read that using the
TCP/IP call is not safe on dialect 3, IB 6?
So my question is how do I correct this issue? Is it safe to just
connect using the "localhost:c:/test.gdb"? And is there any issues
with the commit retaining?
Thanks much!!
having?
Here goes...
Okay, I have a multithreaded client that talks directly to the IB
API, ( using isc_ ... calls, I put a wrapper around this in MS V6
C / C++ )
Thread1 starts and calls isc_attach_database(...) using the connect
string "c:\test.gdb". Thread1 creates a transaction, etc, etc, then
does an INSERT and calls isc_commit_retaining(...). At this point
another thread Thread2 wakes up and tries to connect to the database
using the same string "c:\test.gdb" and the isc_attach_database(...)
call. What happens is the isc_attach_database call locks and never
returns. Meanwhile Thread1 has finished it's work and attempts to
finalize the transaction by calling isc_commit_transaction(...)
however, Thread1 gets locked in the isc_commit_transaction call. Now
both threads are locked and I'm dead.
This is but one of the issues that I have seen but overall it's the
same for all my deadlocks. So I found some information that said
that this can be prevented by using TCP/IP as the connection.
Thus: "localhost:c:/test.gdb". However, I also read that the issue
is in the commit retaining call? Finally, I read that using the
TCP/IP call is not safe on dialect 3, IB 6?
So my question is how do I correct this issue? Is it safe to just
connect using the "localhost:c:/test.gdb"? And is there any issues
with the commit retaining?
Thanks much!!