Zach Saw wrote:

> I've got a multithreaded application that does the following
> (simplistically speaking):
>
> thread 1: insert a record ("RECORD1"), commit, signal wake for thread 2
> thread 2: select * from table
>
> the DB connection is ReadCommitted and Lockwait is true. I'm using
> IBPP for firebird access.
>
> the problem is, thread 2 cannot access to RECORD1 yet as the select
> statement reveals it is not available. I have to refetch a few times
> to get it stably read in RECORD1. How do we make sure Firebird returns
> the committed result set instead of returning the one prior to the
> commit?

By starting a new transaction on thread 2. Transactions should
see a stable view of the database. I know your using read
committed, but that's unwise unless you've got one of the
interface layers that insists on having an open transaction
while data is displayed. Learn to work with ACID transactions,
not against them.

>

Regards,


Ann