--- In firebird-support@yahoogroups.com, Guido Klapperich
<guido.klapperich@...> wrote:

>
> I have two databases, one server database and one client database on a
> laptop. Every day data is imported from the server to the client
> database. My app works like this:
>
> 1) Connect to the server and client database within one transaction
> (using the 2PC protocol)
> 2) Look in table SYNC_TASKS if there is synchronization task for me
> 3) If a task is found, log the start of the synchronization task
> 4) Synchronize the data
> 5) Log the end of the synchronization task
> 6) commit transaction
> 7) disconnect from both databases
>
> Now at point 5) the network connection has been interrupted and
> therefore the transaction is left in limbo state. So far all is

clear to me.

> Now when I start my app, I get at point 2) the following error
> Error: ISC ERROR CODE:335544459
> ISC ERROR MESSAGE:
> record from transaction 59681 is stuck in limbo
>
> I don't understand, why a select on table SYNC_TASKS causes a deadlock.
> I thought, because of the multi generation architecture of FB it is
> impossible to create a deadlock, when reading data.
> Perhaps someone can tell me where my error in reasoning is.
>

Dead lock <> Limbo.

But I believe your theory is incorrect. The connection is interupted
at point 6 rather than point 5. If you do some reading on the 2PC
protocol, a limbo transaction occurs when the database doesn't know
whether the commit actually occurred in the other database. It needs
your assistance to decide whether to commit or rollback transaction 59681.

MGA is still vulnerable to limbo transactions. What if your query
reads a record modified by 59681? Does it show that record or does it
perform garbage collection because that record is rolled back?

Take a look at:
http://en.wikipedia.org/wiki/2-phase_commit

for some basic information.

Adam