Hello, I posted this message on Friday afternoon but did not get any
response. Can any confirm if this is a bug in the isc API's or if
this is my usage. I believe this is a bug because I can produce the
same API deadlock in isc_attach_database(…) as well. If I create a
thread that only calls isc_attach_database(…) and then start 100
instances of this thread in a loop the API will deadlock and none of
the isc_attach_database(…) calls return. The app. is stalled.

If this is a bug has it been fixed? If not, how is my usage wrong?


Can anyone help with a database deadlock?

Here is where I am at:
FB v1.0.0.576
I have two threads. T1 and T2. Each thread has its own connection to
the database, e.g., "localhost:c:/database.gdb". And each
tread
started its own transaction using the following tpb:

static char trans[] =
{
isc_tpb_version3,
isc_tpb_write,
isc_tpb_read_committed,
isc_tpb_no_rec_version,
isc_tpb_wait,
'\0',
};

Both threads are trying to access the same table, "MediaItem"
and
update a column called "Istate" at the exact same time ( as
exact as
you can get on a single processor box )

T1 is calling:
isc_dsql_execute_immediate(status, &m_hDB, &hMyTrans, 0, pSql,
SQL_DIALECT_CURRENT, pParams);

with the sql statement: "UPDATE MediaItem SET IState = ? WHERE
IState
= ?"

and T2 is calling:
isc_dsql_fetch(status, hStmt, 1, pSqlResults);

with the sql statement: "SELECT * FROM MediaItem WHERE Mkey = ?
AND
Istate = ?"

And that would be all she wrote. Neither called retuned and are at
present blocked. I broke into the debugger and got the following
info:

Call stacks for both threads ended with:
GDS32
WS2_32
MSAFD
NTDLL (ret 0ch)

When I look at the watch window, I can see the status vector has been
set:
status[0] = 1
status[1] = 335544726
status[2]= 0
however, as I mentioned the isc calls never returned control to the
application. Can anyone explain what is going on here? Is my tpb
bad?

Also if I use iblockpr.exe I don't see any locks are deadlocks? It
looks as if the engine is done but the api is stuck?