Subject | Re: [firebird-support] Re: result set not updated immediately after post |
---|---|
Author | Olivier Mascia |
Post date | 2005-10-25T17:58:39Z |
Le 25-oct.-05 à 18:25, Zach Saw a écrit :
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.)
--
Olivier
> 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.)
--
Olivier