Subject Re: Anyone know what this error means, isc_req_sync?
Author kshenes
--- In, Helen Borrie <helebor@t...>
> At 02:12 PM 27/07/2004 +0000, you wrote:
> >This is very helpful, Thanks. Now an addition tidbit. I am
> >encountering this error when retrying an a select statement after
> >encountering a limbo transaction error. So does this mean the
> >transaction is out of limbo state and the query has proceeded
> >I retry? What is the best way to handle limbo transactions errors
> >encountered during a query?
> Uh-oh, this could be a different sort of sync error altogether.
> transactions don't arise in a transaction involving only one
database, and
> limbo transactions have no capability to "unlimbo" themselves. A
> transaction is a two-phase, multi-database transaction that gets
left in an
> indeterminate state when the connection is lost to one or other
> before the two-phase commit completes.
> If you are getting messages about limbo transactions, you'll need
to fix
> them. This requires use of the gfix utility and Chapter 39 of The
> Book (coming real soon! :-) ) Absent The Firebird Book, study the
> relevant section in the IB6 OpGuide.pdf.
> /heLen


Am I incorrect in thinking that I can get isc_rec_in_limbo status
returned when a transaction is part way throught the 2 phase commit
process to multiple databases?

If process A commits 1 record to table FOO on machine x, and y. Then
process B recevies a event saying table FOO had an insert, so process
B does a selectALL on FOO while process A is part way through the 2
phase commit between x and y doing an update on FOO. Can the
isc_dsql_fetch done by process B return isc_rec_in_limbo? That is
what I am seeing. When I retry the isc_dsql_fetch after waiting a
bit, I get the isc_rec_sync. The transaction that process A commited
across the machines x and y is not in limbo on either machine
according to process A. The commit returned success.