Hello:

Actually, it does not seem to matter. I have tried various isolation
levels however the deadlock does not appear to be in the transaction
but in the API methods themselves. Just trying to attach from two
separate threads will cause a lock. For example: Thread1 calls
isc_attach_database() and then thread2 calls isc_attach_database().
Thread2 will block waiting to enter the isc_attach_database() call.
This however causes thread1 to also block on its next call into the
API, like calling isc_start_transaction(). So I end up with both
threads blocking on API calls?

Well, that is if I use the connection string of "c:\test.gdb". I
found that if I use the TCP/IP connection string
of "localhost:c:\test.gdb" both threads will then attach and appear
to work. My concern, is this correct? Is it safe to simply change
the connection string and forget about this issue? I'm concerned
that I will get past this and find other problems down the road.
Unfortunately, I have not found any documentation on what the
possible connection strings are and what the really are doing.

--- In ib-support@y..., "Wilson, Fred" <fred.wilson@b...> wrote:
> What transaction isolation level are you using ??
>
>
> Best,
> Fred Wilson
> SE, Bell & Howell
> fred.wilson@b...
>
>
>
> -----Original Message-----
> From: nitaligavino [mailto:Dan.Crea@a...]
> Sent: Monday, April 01, 2002 8:27 AM
> To: ib-support@y...
> Subject: [ib-support] Concurrent API calls into gds32 cause lock
>
>
> 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!!
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@e...
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/