Hi Fred:
I have a single multithread application. Each thread creates its own
connection to the database when the thread is started. These threads
then live thought the application lifecycle. When there is db work
to be done, an idle thread is woken up and it creates a new
transaction. On work completion the transaction is committed or
rolledback. Typically, I have at most 12 threads or 12 connections
to the database. But this number varies.

This issue is reproducible, but not at will. I have not been able to
create a tester that can produce this on demand. However I run into
this problem at least 1 time every two days or when the applications
load increases and all threads are running.



--- In ib-support@yahoogroups.com, "Wilson, Fred" <fred.wilson@b...>
wrote:

> How are you executing those two calls "at the same time" ??
> Is this from a single application, with multiple threads, or from

two

> separate applications ??
>
> Best regards,
> Fred Wilson
> SE, Bell & Howell
> fred.wilson@b...
>
>
>
> -----Original Message-----
> From: nitaligavino <Dan.Crea@a...> [mailto:Dan.Crea@a...]
> Sent: Monday, December 16, 2002 11:21 AM
> To: ib-support@yahoogroups.com
> Subject: [ib-support] Need advise
>
>
> Hello:
>
> I seem to be running into a reoccurring issue I was hopping someone
> might be able to offer some advise on. It seems, under the right
> conditions, the FB gds32 becomes stalled and any call into the

gds32,

> via the gds32 API's, will block indefinitely until you terminate

the

> application. I have narrowed it down to the following two calls:
>
> isc_dsql_fetch(...)
> isc_dsql_execute_immediate(...)
>
> For some reason, if these two calls occur at the same time the

gds32

> locks and becomes stalled never to return to the caller again.
>
> Has anyone else experienced an issue like this?
> Can anyone offer some advise on how to work around this issue or

how

> to figure out what exactly is happing?
>
> Also, during the stall, I ran iblockpr to see if there was a

deadlock

> reported. See snip-it. From what I understand of the output,

which

> is not much, no deadlock occurred.
>
> P.S Does anyone know how to read this stuff!!
>
> LOCK_HEADER BLOCK
> Version: 114, Active owner: 0, Length: 32768, Used:
> 24884
> Semmask: 0x0, Flags: 0x0001
> Enqs: 160067, Converts: 0, Rejects: 21625,

Blocks:

> 0
> Deadlock scans: 13, Deadlocks: 0, Scan interval:

10

> Acquires: 385444, Acquire blocks: 0, Spin count: 0
> Mutex wait: 0.0%
> Hash slots: 101, Hash lengths (min/avg/max): 0/ 0/ 3
> Remove node: 0, Insert queue: 0, Insert

prior:

> 0
> Owners (19): forward: 16852, backward: 23968
> Free owners (24): forward: 17984, backward: 16920
> Free locks (32): forward: 13792, backward: 13136
> Free requests (67): forward: 23392, backward: 23296
> Lock Ordering: Enabled
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/

>
>
>
> [Non-text portions of this message have been removed]