db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Srivastava" <ashish_s...@rediffmail.com>
Subject Re: Network Server XA Support
Date Sun, 31 Oct 2004 07:05:03 GMT
I have a query, what is the significance of XA support in embedded mode. 

On Fri, 29 Oct 2004 Kathey Marsden wrote :
>I wrote up a functional description of Network Server XA support.  I put
>it in HTML as the straight text email version just seemed kind of hard
>to read.  I hope that is ok.
>Please post any input.  It would also be great to identify folks who
>might be early users of this feature.
>The Derby embedded driver provides XA support. This project will
>extend XA support to Network Server. Network Server will be enhanced
>to provide DRDA XAMGR level 7 support so that DRDA clients supporting
>XAMGR level 7 can send XA requests to Network Server. Initial testing
>will be done with the IBM DB2 Universal JDBC driver using the
>com.ibm.db2.jcc.DB2XADataSource to get XA Connections.
>The XAMGR level 7 support is described in the XAMGROV section of
>the Distributed Data Management Architecture Specification DRDA V3,
>Vol 3.
>Other relevant sections are XAMGR, XID, XAFLAGS, XIDCNT, SYNCCTL
>DRDA support is based on The XA+ Specification, also available
> from the Open Group at
>Below is a excerpt from the XAMGROV section of the DDM
>Specification which Network Server will support.
>Transactional Processing Support
>level 7 is a manager object of DDM that provides a connection
>architecture that will
>the application to perform the operations involved in protecting a
>DRDA resource. The
>functionality is summarized below:
> 	Unit of Work)
>Provides the application with the ability to
> 	register/start a transaction with the DBMS and
> 	the connection with the transaction’s XID. A valid XID
> 	represents a Global
> 	that requires two-phase protection, while a NULL XID represents an
> 	transaction. The functionality also provides the application with
> 	the ability to
> 	or resume existing transaction branches at the application server. A
> 	timeout value is also
> 	that allows the transaction to be rolled back when it exceeds the
> 	timeout limit.
> 	association)
> 	application uses this functionality to inform the application server
> 	that it is ending a
> 	Transaction and is dissociating the XID from the connection. It also
> 	provides the
> 	with the ability to suspend or fail a transaction branch. Suspend
> 	with migrate
> 	the application the capability of moving the resources associated
> 	with a transaction
> 	from one connection to another.
> 	to Commit)
> 	the application with the ability to perform the first phase of the
> 	two-phase protocol,
> 	involves informing a DBMS to prepare the transaction branch for
> 	commit.
> 	the application with the ability to carry out the second phase of
> 	the two-phase
> 	which involves committing the Global Transaction. The function also
> 	allows the
> 	to perform a one-phase optimization.
> 	the application with the ability to roll back a Global Transaction.
> 	The function also
> 	the application to perform a one-phase optimization.
> 	Indoubt List)
> 	any given time, the application can use this function to obtain a
> 	list of Prepared and
> 	completed Transactions at the DBMS. The application can then compare
> 	the list
> 	its own and commit and roll back the transaction branches
> 	accordingly.
> 	DBMS will keep the knowledge of a heuristically completed
> 	transaction branch until it is
> 	by the application to forget the transaction branch. The application
> 	uses this
> 	function to inform the DBMS which heuristically completed
> 	transaction branch it
> 	forget.
>following elements of the XAMGR level 7 support will not be supported
>by Network Server at this time .
> 	ability to migrate cursors, RDB protected resources (for example,
> 	temp tables), and external savepoints from one XA protected
> 	connection to another.
> 	for the RLSCONV parameter to release a connection to a different
> 	application
> 	for the timeout instance variable on the SYNCCTL codepoint as
> 	currently the embedded XA Resource does not support setTimeout()
>with the DB2 Universal JDBC Driver
>XA support for Network Server can be accessed using the DB2
>Universal JDBC Driver's XA DataSource
>An example of obtaining an XA connection with the DB2 Universal
>JDBC Driver.
>xaConnection = null;
>Connection conn = null;
>String driver =
>DB2XADataSource ds =
>new DB2XADataSource();
>ds.setDatabaseName(dbname +
>// Network Server requires JDBC type 4 driver
>= ds.getXAConnection("auser", "shhhh");
>= xaConnection.getConnection();
>ij currently has unpublished syntax that is used solely for XA
>testing.  This support will be extended to support Network server so
>that tests develeloped using the ij xa syntax can be used for network
>server testing.
>Ij will support the  framework property setting DerbyNet to
>indicate that the test should be run against Network Server. Since
>this support is just for testing, ij will always connect to
>localhost, port 1527 with the xa_datasource command.
>An example usage of ij will be as follows:
>java –Dframework=DerbyNet org.apache.derby.tools.ij
>ij> xa_datasource ‘wombat’;
>ij> xa_connect;
>ij> xa_start xa_noflags 1;
>IBM DB2 Universal JDBC Driver.
>Some changes may be required for the IBM DB2 Universal JDBC
>Driver, so XA support may require a later version than 2.4
>javax.transaction.xa package
>In order to use the Network Server XA functionality, the server
>must be running with a jdk with javax.transaction.xa suppport so will
>not be supported in JSR 169 configurations.
>Existing embedded XA tests will be run against Network Server.
>Changes to support XA connections should not affect performance of
>non-XA connections. XA performance will be measured in comparison to
>embedded performance to ensure that Network XA Connections do not
>have a significant performance impact. We will compare to embedded to
>ensure that the XA performance ratio embedded/network server is
>comparable to to the tests with non-XA connections.
>We will add two new classes to org.apache.derby.drda.
>This class will extend the existing
> 	Database class which holds all of the connection information for a
> 	database connection. DRDAXADatabase will have additional fields to
> 	hold the XAResource and XAConnection and will override the Database
> 	class's makeConnection method to make an XA connection instead. On
> 	connection initialization, the DRDAProtocol class will create a new
> 	XADatabase if the client sends XAMGR level 7 in the mgr levels.
>This class will extend DRDAProtocol and
> 	will have all of the XA Specific protocol to handle the SYNCCTL
> 	requests and send appropriate responses. In XAMGR level 7 there is a
> 	one to one mapping of the XAResource methods to the SYNCCTL commands
> 	sent and the xaflags. So generally for XA connections, the SYNCCTL
> 	calls translate directly into embedded XA calls and returns either
> 	XAResource.XA_OK on success or the XAException errorcode on failure.
> 	If the XID has formatID -1 this indicates a local connection and is
> 	handled accordingly.
>Other changes will include adding an isXARequester() to the
>AppRequester, adding the new Codepoints and SYNCCTL values to the
>Codepoint class and other miscellaneous support.
>Note, The one flag that does not seem to be defined for DRDA is
>XAResource.TMONEPHASE. Currently JCC sends XAResource.TMONEPHASE in
>the event of a one phase commit, and Network Server recognizes this,
>but it is not clear whether this is standard.

View raw message