Subject Re: [firebird-support] Re: result set not updated immediately after post
Author Olivier Mascia
Le 25-oct.-05 à 18:25, Zach Saw a écrit :

> Commit, haven't tried CommitRetain.

You shouldn't. Wanted to make sure Commit was used.
Asking the obvious, are you 100% sure of the signaling between the
threads ?

Now to the SQL side of things, I would have expected that thread 2,
preparing and running a query inside a read-committed transaction
would see others attachment committed transactions data immediately
with no caching of any sort altering the result.

Is this assumption wrong ?
Should this be considered a bug ?
When one says that a read-committed transaction sees committed data
by other transactions, how should this be interpreted? A read-
committed trans can and will probably, soon, see other committed
updates? Or a read-committed trans _must_ see other commits immediately?

Zach, how many other threads/processes have you running and what do
they do ?
Isn't this just an expected side-result of versioning ?

Could you re-run your test using IBPP::ilReadDirty and report again
(which is read_committed with rec_version while ilReadCommitted is
read_committed with NO_rec_version) ?

(I doubt this is IBPP related. If it turns to be, we'll move the
thread to the list where it belongs.)