Olivier Mascia wrote:

>
> So ReadCommitted makes use of isc_tpb_read_committed and
> isc_tpb_no_rec_version, which I believe is perfectly correct.

Grumph. It's a great combination if you don't care about
data consistency and like getting deadlock errors and waiting.

>
> Does your 'thread2' execute a previously prepared SELECT or do you
> really re-prepare/execute a new SELECT after 'thread1' signaled the
> commit done ?

There's no reason to re-prepare requests. You can use a prepared
request in different transactions and get different results.

>
> Does thread1 really Commit or CommitRetain ?

Shouldn't matter. Which of course raises the question, "what is
going on?"

Here's what's been said...

> I've got a multi threaded application that does the following
> (simplistically speaking):
>
> thread 1: insert a record ("RECORD1"), commit, signal wake
> for thread 2
> thread 2: select * from table

Each thread has its own connection. Are the connections
classic? If so, it's possible that the process serving
the connection for thread 2 hasn't picked up the new state
of transactions. Now how exactly is that supposed to work...

Hmm... verify that the connections are classic, and I'll
go dig through the interprocess communication around
committed transaction states - sounds like a possible
bug. If the connections are SuperServer, I'll look
elsewhere. But I still think that grown-up programmers
use repeatable read transactions.

Cheers,


Ann