Hi Sean:

I modified my class wrapper to serialized all calls into the client,
for example:

… some code …
{
AT_Lock lock(&m_guard); // This is a global critical
section
lResult = isc_dsql_fetch(status, hStmt, 1, pSqlResults);
}

… some code …

So no two threads can be in the client API at the same time.
However, the problem I'm experiencing is still present. In fact
after serializing all the isc API calls, the problem is more
frequent. What I have discovered is that whenever I issue an
isc_dsql_fetch(..) that has a where clause or group by that
references a VARCHAR column the isc_dsql_fetch(…) call gets hung in
the gds32 client under certain circumstances. According to the
debugger, the isc_dsql_fetch(…) is blocked waiting on an event to be
signaled.

Every time this stall occurred I'm performing a fetch on one of these
SQL statements:

"SELECT * FROM MediaItem WHERE Mkey = ? AND ToAddress = ?"
or
"SELECT DestinationDomain FROM OutboundMedia WHERE RetryCount = 0 AND
ResponderId = ? GROUP BY DestinationDomain"

The ToAddress and DestinationDomain are both un-indexed VARCHAR's.

I'm in the process of build a debug version of Firebird so I can get
into the code and see what is really going on.

Anyway, is this issue related to bug #446227?

Best regards,
Dan

--- In ib-support@yahoogroups.com, "Leyne, Sean" <sleyne@a...> wrote:
> Dan,
>
> > I considered this but it seems that serializing the FB API should
not
> > be required. It should be thread safe itself and if not that's a
> > bug.
>
> The Client is NOT thread safe (hasn't been since IB 5.0) so this is
a
> old issue -- which has been logged in the FB bug tracker for some
time.
>
> I've posted a message to the developer mailing list so see if this
can
> be addressed for the v1.5 release. Keep following the Firebird
release
> announcements for further details on it's progress.
>
>
> --
> Sean Leyne
>
> - FirebirdSQL Foundation, Sponsor - Silver Level
> - FirebirdSQL Foundation, Member
> - FirebirdSQL Project Admin (one of many)
> http://www.FirebirdSQL.org