> Sean, the solution is simple and elegant: Capture the transaction state
> information from the lead transaction using the transaction info
> mechanism then import it to secondary connection transactions with the
> transaction parameter block.
It requires two network transfers of (part of) TIP, which size is unknown -
it
could be few bytes or few megabytes. I don't understand why do you ignore it...
> Internally, creation a transaction object
> using the lead transaction's state data. To be safe, mark at least the
> secondary transaction a read-only. Have only the lead
> connection/transaction do the commit. To avoid garbage collection
> issues, it would be best to commit the lead transaction last.
I see no reason for such limitations. Could you explain ?
> This should work for both the server and classic versions.
>
> I think the whole thing can be done in tra.cpp and associated headers to
> define the new parameters. If the implementation takes more than a
> couple of hours, something is seriously wrong.
But we could spend a bit more time and avoid potential performance
penalty...
> Since it's small and localized, I suggest you do it on your private
> code. Fighting it out with the NIH crowd would take more time than the
> implementation.
Should i make offended face here ? Where do you see "NIH crowd" ?
Is it correct to blame all participants after rude talk of one local clown ?
Regards,
Vlad
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
