In the first case you get <global-transactions-protocol>None</global-transactions-protocol>
in the second case <global-transactions-protocol>OnePhaseCommit</global-transactions-protocol>
Showing posts with label xa. Show all posts
Showing posts with label xa. Show all posts
Saturday, April 8, 2017
Support Global Transactions
For a non-XA Datasource, you can choose to "Support Global Transactions" or not:
In the first case you get <global-transactions-protocol>None</global-transactions-protocol>
in the second case <global-transactions-protocol>OnePhaseCommit</global-transactions-protocol>
In the first case you get <global-transactions-protocol>None</global-transactions-protocol>
in the second case <global-transactions-protocol>OnePhaseCommit</global-transactions-protocol>
Saturday, December 17, 2016
XA transactions explained : TLOG, prepare, recover, determiner
https://blogs.oracle.com/WebLogicServer/entry/exiting_new_jta_12_1
about the "removal of TX logging feature"
and more in detail
great explanation by Monica Riccelli!
in WLS 12.2.1, check in Cluster/JTA the properties "Write recovery logs when determiners configured" and "determiner".
Use: -Dweblogic.debug.DebugJTAXA=true -Dweblogic.debug.DebugJTA2PC=true -Dweblogic.debug.DebugJTARecovery=true (see https://blogs.oracle.com/vijaya/entry/weblogic_server_debug_flags_jta )
Plus: Cluster Transaction Affinity explained here http://docs.oracle.com/middleware/1213/wls/WLJTA/trxcon.htm#WLJTA386
about the "removal of TX logging feature"
and more in detail
great explanation by Monica Riccelli!
in WLS 12.2.1, check in Cluster/JTA the properties "Write recovery logs when determiners configured" and "determiner".
Use: -Dweblogic.debug.DebugJTAXA=true -Dweblogic.debug.DebugJTA2PC=true -Dweblogic.debug.DebugJTARecovery=true (see https://blogs.oracle.com/vijaya/entry/weblogic_server_debug_flags_jta )
Plus: Cluster Transaction Affinity explained here http://docs.oracle.com/middleware/1213/wls/WLJTA/trxcon.htm#WLJTA386
Thursday, October 29, 2015
javax.transaction.SystemException: SubCoordinator not available
If you see this "javax.transaction.SystemException: SubCoordinator not available" in the logs, AND you have recently moved your domain to new servers, it could very well be that you need to purge your TLOG DB tables (of file store).. in fact, IP address of previous servers is still hardcoded in the TLOG info, so those TX will still linger around failing recovery until the Abandon Timeout is hit (read the "Moving the Server" chapter here http://docs.oracle.com/cd/E24329_01/web.1211/e24377/trxman.htm#WLJTA176 " the server identity may no longer match the information stored in the transaction logs"
Tuesday, October 20, 2015
ORA-24756: transaction does not exist
Here is the stacktrace:
If you get this error, you must be using Oracle RAC and XA.
You must carefully craft the various timeouts in WebLogic and in Oracle DB.
See Oracle note "Troubleshooting ORA-24756 while Running an XA Program or MSDTC with the Oracle RDBMS (Doc ID 1076242.6)". THE rule is: global transaction timeout < session timeout < distributed_lock_timeout . See also "Recommended Timeout Configuration When Using an External Transaction Processing Monitor and XA with Oracle (Doc ID 338880.1)" .
Each MDB has a specific timeout, but this should not be involved in the issue (this in the weblogic.ejb.jar.xml DD https://docs.oracle.com/cd/E13222_01/wls/docs103/ejb/DDreference-ejb-jar.html )
So you should end up with this configuration in config.xml and the "$XA_DATASOURCE"jdbc.xml
java.sql.SQLException: ORA-24756: transaction does not exist at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:392) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:385) at oracle.jdbc.driver.T4CTTIfun.processError(T4CTTIfun.java:1018) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) at oracle.jdbc.driver.T4CTTIOtxen.doOTXEN(T4CTTIOtxen.java:166) at oracle.jdbc.driver.T4CXAResource.doTransaction(T4CXAResource.java:757) at oracle.jdbc.driver.T4CXAResource.doPrepare(T4CXAResource.java:518) at oracle.jdbc.xa.client.OracleXAResource.prepare(OracleXAResource.java:713)
If you get this error, you must be using Oracle RAC and XA.
You must carefully craft the various timeouts in WebLogic and in Oracle DB.
See Oracle note "Troubleshooting ORA-24756 while Running an XA Program or MSDTC with the Oracle RDBMS (Doc ID 1076242.6)". THE rule is: global transaction timeout < session timeout < distributed_lock_timeout . See also "Recommended Timeout Configuration When Using an External Transaction Processing Monitor and XA with Oracle (Doc ID 338880.1)" .
Each MDB has a specific timeout, but this should not be involved in the issue (this in the weblogic.ejb.jar.xml DD https://docs.oracle.com/cd/E13222_01/wls/docs103/ejb/DDreference-ejb-jar.html )
<transaction-descriptor> <trans-timeout-seconds>2400</trans-timeout-seconds> </transaction-descriptor>
So you should end up with this configuration in config.xml and the "$XA_DATASOURCE"jdbc.xml
> config/jdbc/<datasource>-jdbc.xml <jdbc-xa-params> <keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete> <xa-end-only-once>true</xa-end-only-once> <xa-set-transaction-timeout>true</xa-set-transaction-timeout> <xa-transaction-timeout>3300</xa-transaction-timeout> <xa-retry-duration-seconds>3600</xa-retry-duration-seconds> </jdbc-xa-params> > config/config.xml <jta> <timeout-seconds>3000</timeout-seconds> <forget-heuristics>false</forget-heuristics> <max-resource-requests-on-server>1000</max-resource-requests-on-server> </jta>
Thursday, May 3, 2012
xa transactions vs local
Reblogging an excellent explanation by Mike:
http://www.theserverside.com/discussions/thread.tss?thread_id=21385
An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.
The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.
In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).
For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".
-Mike
http://www.theserverside.com/discussions/thread.tss?thread_id=21385
An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.
The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.
In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).
For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".
-Mike
Wednesday, September 14, 2011
Pending XA Transactions on Oracle DB
With the statement:
SELECT formatid, globalid, branchid FROM SYS.DBA_PENDING_TRANSACTIONS;
select * from DBA_2PC_PENDING;
select * from V$GLOBAL_TRANSACTION
you should be able to extract info on the pending XA transactions.
This is an excellent document on the parameters regulating the timeout on Oracle DB with XA transactions
More interesting reading here:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_xa.htm
two-phase commit = prepare + commit, then forget
DEFAULT_XA_TIMEOUT = 60
XA_SETTIMEOUT defaults to 60
DISTRIBUTED_LOCK_TIMEOUT specifies the amount of time (in seconds) for distributed transactions to wait for locked resources.
Generally, these timeouts should be set in the following order:
1. TM’s global transaction timeout (or the JTA timeout) <
2. SesTm and SesWt (Transaction Timeout for JDBC or PL/SQL) <
3. DISTRIBUTED_LOCK_TIMEOUT <
4. Either of CONNECT_TIME or IDLE_TIME
SELECT formatid, globalid, branchid FROM SYS.DBA_PENDING_TRANSACTIONS;
select * from DBA_2PC_PENDING;
select * from V$GLOBAL_TRANSACTION
you should be able to extract info on the pending XA transactions.
This is an excellent document on the parameters regulating the timeout on Oracle DB with XA transactions
More interesting reading here:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_xa.htm
two-phase commit = prepare + commit, then forget
DEFAULT_XA_TIMEOUT = 60
XA_SETTIMEOUT defaults to 60
DISTRIBUTED_LOCK_TIMEOUT specifies the amount of time (in seconds) for distributed transactions to wait for locked resources.
Generally, these timeouts should be set in the following order:
1. TM’s global transaction timeout (or the JTA timeout) <
2. SesTm and SesWt (Transaction Timeout for JDBC or PL/SQL) <
3. DISTRIBUTED_LOCK_TIMEOUT <
4. Either of CONNECT_TIME or IDLE_TIME
Subscribe to:
Posts (Atom)
