In order for me to use 2.1.0, I had to change the transaction manager slightly, so as not to initiate background recovery against my Oracle DB. Is this something that you would consider adding to Bitronix in future releases?
Hi,I've been using Bitronix transaction manager successfully since 2010 (v2.1.0). I have only recently returned to your website and noticed that 2.1.4 is now available.
If you're using BTM only for testing, you can set the ignoreRecoveryFailures to true on your PoolingDataSource but keep in mind that this setting should _never_ be used on production as, once again, BTM cannot guarantee atomicity without a working recovery.
Hi,Why wouldn't you want background recovery to run on your DB? BTM needs to run its recovery process from time to time to make sure aborted transactions don't stay in limbo forever, it's required to guarantee the atomicity of your transactions.
On Thu, Nov 21, 2013 at 1:31 PM, mcnamara steven <[hidden email]> wrote:
Thank you for replying.
My understanding is that the background recovery is there to recover transactions that were inflight when an outage occurs. Is that correct?
Also BTM (via Oracle's XA driver) requires access to system tables in order to make transaction recovery possible. I don't have access to these tables and the DBA's will not grant them. The fact that the JDBC sessions do not have access causes the service to fail at startup. This is due to the recovery process being started in the transaction manager initialisation.
I am successfully using BTM to orchestrate the 2PC of the XA resources that I'm using which includes several MQ fire and forget messages and oracle databases.
I didn't realise that recovery errors could be ignored in the PoolingDataSource. Is it possible to do this on the transaction manager too?
Sent from my iPad
On 22 Nov 2013, at 08:22, Ludovic Orban <[hidden email]> wrote:
I'm sorry but I can't stress that enough: if you don't have proper recovery working, you'd better NOT use XA at all and consider an alternative way of keeping your transactions atomic.
The transaction manager will always run recovery, not matter what happens. The only way around that is to tell the resources to ignore recovery failures and tell the TM that everything went fine and nothing needs to be done, this is exactly what the ignoreRecoveryFailures flag is about. In a nutshell, you have to set that on all your problematic resources, there's no global equivalent.
BTW, since Oracle 11 less privileges are required to perform XA recovery, see: http://docs.oracle.com/cd/B28359_01/java.111/b31224/xadistra.htm#sthref1311
Yes, the background recovery is there to clean up whatever is left after an outage. That includes the JVM running BTM, the DB itself or the network between the two. You have to know that Oracle keeps hard locks on rows that are part of an XA transaction (much like select for update) and only releases them when the transaction is terminated... which could never happen if a problem happens while a transaction entered the two-phase commit cycle and recovery never cleans up the mess.By ignoring this, you (and your DBAs) are pretty much reducing the usefulness of XA to nil: you're paying a high price to run your transactions in two phases but you're not getting the absolute guarantee that your data is safe.
On Fri, Nov 22, 2013 at 1:17 PM, Steven McNamara <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|