I will see if I can come up with a solution for Firebird 3 without needing
RDB$TRANSACTIONS to be unprotected, but doesn't - potentially - degenerate
to iterating over a list of thousands if not millions of transaction
records when recovering a distributed transaction.
Am i already told
On Sat, 10 May 2014 10:53:05 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
I will see if I can come up with a solution for Firebird 3 without
needing
RDB$TRANSACTIONS to be unprotected, but doesn't - potentially -
degenerate
to iterating over a list of thousands if not millions of
On Sat, 10 May 2014 13:46:46 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
Surprise : after you got list of tx numbers it can be used to query
RDB$TRANSACTIONS for additional info.
But then I could just as well query RDB$TRANSACTIONS directly. I don't
know the Firebird
On Sat, 10 May 2014 13:46:46 +0300, Vlad Khorsun wrote:
Surprise : after you got list of tx numbers it can be used to query
RDB$TRANSACTIONS for additional info.
But then I could just as well query RDB$TRANSACTIONS directly. I don't
know the Firebird transaction id: I need to identify
After thinking more on it...
I could (with FB 2.5 and later) also query with
RDB$TRANSACTION_DESCRIPTION = X'' (where X'' is the serialized Xid
I am looking for) although I wonder about its performance implications. On
the other hand, recovery situations should be rare so it might
On Wed, 7 May 2014 18:44:13 -0400, Claudio Valderrama C.
cva...@usa.net
wrote:
As the value of RDB$TRANSACTION_STATE is modified, I assume
this code (or
something very similar) is actually called, but then the `else` branch
shown above. What does TRA_prepare2 mean here? Note that the specific
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Martes, 06 de Mayo de 2014 15:41
After successfully recovering a transaction that way, the current
implementation in Jaybird deletes the entry in RDB$TRANSACTIONS
(probably as a form of house-keeping, or
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Martes, 06 de Mayo de 2014 15:41
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
2) Is there an alternative
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
I assume
On Wed, 7 May 2014 05:00:43 -0400, Claudio Valderrama C.
cva...@usa.net
wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
2) Is there an alternative to removing this information?
Mark, I had
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
I was a bit wrong - when
On 7-5-2014 20:54, Vlad Khorsun wrote:
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Miércoles, 07 de Mayo de 2014 8:14
As the value of RDB$TRANSACTION_STATE is modified, I assume
this code (or
something very similar) is actually called, but then the `else` branch
shown above. What does
When Jaybird uses distributed transactions, it adds information on the
Xid (the distributed transaction id) in the call to isc_prepare.
When the transaction is limbo-ed by destroying the connection, another
connection can recover that by performing a reconnect and then either
committing or
14 matches
Mail list logo
