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. > > I was a bit wrong - when distributed transaction is *committed* by > connection > which started it *and* if there was provided information about all > participants (i.e. > there is description record) - in this case engine automatically deletes > record in > RDB$TRANSACTION.
Jaybird provides its own description record with a serialized Xid (see https://sourceforge.net/p/firebird/code/HEAD/tree/client-java/trunk/src/main/org/firebirdsql/jca/FBXid.java#l206 ) > In other cases (rollback by original connection, no description or > commit\rollback > after reconnect) - record is not deleted. I think it is necessary to allow > transaction > manager to handle local sub-transaction again, if necessary (if recover > attempt failed > at another node, for example) Yes, but Jaybird doesn't actually use the transaction manager in Firebird (except for a basic prepare and commit/rollback). >> I assume it doesn't survive a backup/restore cycle, otherwise we have a >> problem with duplicate transaction ids ;) > > Exactly :) > > >>>> 2) Is there an alternative to removing this information? >>> >>> I see no big need to clean up RDB$TRANSACTIONS. If we really want, >> we >>> can >>> make sweep to take care about it - to delete entires which is older than >>> new OIT. >>> But again, i see no real needs to do it. >> >> I am trying to understand why Jaybird deletes the entry. It looks like it >> is doing it, because in a recovery situation it retrieves *all* >> transactions listed in RDB$TRANSACTIONS and iterates over it to match the >> Xid used on prepare to find the right transaction id. This works fine when >> the number of transactions is small, but is probably not a good idea when >> there is a large number of transactions. > > gfix lists in-limbo transactions using > isc_database_info('isc_info_limbo') call. > It doesn't query RDB$TRANSACTIONS for the list, only for the descriptions. I need to match by Xid (or: the serialization of that Xid) that has been stored in RDB$TRANSACTION_DESCRIPTION; I don't know the transaction id before hand. The reason is that in Java distributed transactions, the transaction manager (eg an application server) signals to the resource manager (ie: Jaybird JCA) that it wants to attempt to recover a certain Xid (because its internal administration shows it was prepared but not yet committed or rolled back, or the previous attempt to commit or rollback failed). This may even occur after a restart (so even if I do record keeping in Jaybird, that wouldn't be sufficient). If I can't clear the list, I will need to find a more efficient way of finding the record, because the current method will quickly degenerate in performance if the contents of RDB$TRANSACTIONS grows. In theory I can limit it by only checking the limbo-records, but I could probably use the committed/rolled back information as well to signal that the transaction was already committed or rolled back. I may need to resort to two strategies one for Firebird 3 (or maybe 2.5 + 3.0) and one for older versions). Does anyone know if blob equality checks work with Type 7 blobs (and if so: starting at which Firebird version)? Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
