1300 to 3100 lines of code for XA support (was: Re: plans and estimates for supporting JDBC 3.0) - Mailing list pgsql-jdbc
From | Vadim Nasardinov |
---|---|
Subject | 1300 to 3100 lines of code for XA support (was: Re: plans and estimates for supporting JDBC 3.0) |
Date | |
Msg-id | 200411021447.54010@vadim.nasardinov Whole thread Raw |
In response to | Re: plans and estimates for supporting JDBC 3.0 (Oliver Jowett <oliver@opencloud.com>) |
Responses |
Re: 1300 to 3100 lines of code for XA support
Re: 1300 to 3100 lines of code for XA support (was: Re: plans Re: 1300 to 3100 lines of code for XA support |
List | pgsql-jdbc |
On Wednesday 27 October 2004 16:33, Oliver Jowett wrote: > Yes; there's no point in implementing XA* until we have a 2PC > implementation on the server side to back it up. Ok. I hear that Heikki's 2PC patches are unlikely to get merged any earlier than 8.1. > As I understand it, you do not need an XA implementation to be JDBC3 > compliant anyway. Yes and no. Section 6.5 [1] does not list XA as an explicit requirement for 3.0 compliance. So, yes, you're right. On the other hand, Section 6.2 [2] seems to suggest that you must implement XA, if the backend supports 2PC. > > Is there a plan for doing this and an estimate of the required > > effort? (As far as I understand, support for the XA stuff needs > > to be added on the backend side. Ignoring that for a second, are > > there any estimates for the amount of work required on the driver > > side?) > > It depends on what the server interface to 2PC ends up looking like. I spoke with Tom Lane about this. If I understood him correctly, chances are, the interface will end up looking very much like whatever Heikki currently has. > With current proposals it doesn't seem like much work on the driver > side. To get a better feel for what "not much work" actually looks like, I googled for existing implementations. The lower bound estimate is provided by implementations that "emulate" distributed transactions. The way this works is, you implement XAResource#prepare(Xid) [3] to always return XA_OK. In the second phase, when XAResource.commit(Xid, int) [4] is called, the local transaction is actually committed. Despite the fact that this approach cannot provide transactional semantics, it's pretty widely used. The MySQL JDBC driver used to have this up to and including version 2.0.14 [5]. Since it didn't really work, it was removed from later versions. MySQL's implementation was about 2100+ lines of code [6]. JBoss provides (or used to provide) similar wrappers in its org.jboss.pool.jdbc.xa.wrapper.* package, but I can't seem to find the relevant sources [7]. Jonas, too, provides XA wrappers implemented in 1300+ lines of code [8]. There's also XAPool. The size of its "standard" implementation is about 3100 lines of code[9]. (They have a test case for PostgreSQL [10].) So, based on this, I'd say it takes about 1300 to 3100 lines of code to provide fake XA support. As a side note, it looks like the PostgreSQL JDBC driver used to provide emulated XA support [11]. As far as real implementations go, MaxDB (previously known as SAPDB) claims to support 2PC and its JDBC driver implements XA. The size of MaxDB's implementation is about 1800+ lines of code [12]. One could also look at the size of the relevant .class files in the Oracle JDBC driver as an upper bound estimate. Vadim ------------------------------------------------------------------------------ Footnotes 1. JDBC 3.0 API Compliance, p. 40: | A driver that is compliant with the JDBC 3.0 API must do the | following: | | * Comply with the JDBC 2.0 API requirements | | * Include the following required interfaces: | | * java.sql.ParameterMetaData | * java.sql.Savepoint | | * Fully implement the DatabaseMetaData interface, including the | following methods added in the JDBC 3.0 API: | | * supportsSavepoints | * supportsNamedParameters | * supportsMultipleOpenResults | * supportsGetGeneratedKeys | * getSuperTypes | * getSuperTables | * getAttributes | * getResultSetHoldability | * supportsResultSetHoldability | * getSQLStateType | * getDatabaseMajorVersion | * getDatabaseMinorVersion | * getJDBCMajorVersion | * getJDBCMinorVersion 2. Guidelines and Requirements, p. 38 | * Drivers should provide access to every feature implemented by | the underlying data source, including features that extend the | JDBC API. When a feature is not supported, the corresponding | methods throw an SQLException. The intent is for applications | using the JDBC API to have access to the same feature set as | native applications. 3. http://java.sun.com/j2se/1.4.2/docs/api/javax/transaction/xa/XAResource.html#prepare%28javax.transaction.xa.Xid%29 4. http://java.sun.com/j2se/1.4.2/docs/api/javax/transaction/xa/XAResource.html#commit%28javax.transaction.xa.Xid,%20boolean%29 5. http://prdownloads.sourceforge.net/mmmysql/mm.mysql-2.0.14-you-must-unjar-me.jar?download 6. This is for mm.mysql-2.0.14-you-must-unjar-me.jar: | $ find . -name \*.java | grep xa/ | ./org/gjt/mm/mysql/xa/ClientConnection.java | ./org/gjt/mm/mysql/xa/TwoPhaseConnection.java | ./org/gjt/mm/mysql/xa/TxConnection.java | ./org/gjt/mm/mysql/xa/XAConnectionImpl.java | ./org/gjt/mm/mysql/xa/XADataSourceImpl.java | $ find . -name \*.java | grep xa/ | xargs cat | wc -l | 2176 7. http://jboss.sourceforge.net/snapshots/jboss-head-snapshot.tar.gz This 66MB file does not have anything under jboss-head/pool/src/main/org/jboss/pool/jdbc/xa/wrapper The CVS repository has way too much stuff in it. I'm not sure where to look for org.jboss.pool.jdbc.xa.wrapper.* classes: http://cvs.sourceforge.net/viewcvs.py/jboss/ 8. http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/src/org/objectweb/jonas/jdbc_xa/ | $ cat ./jonas/src/org/objectweb/jonas/jdbc_xa/*.java | wc -l | 1326 9. http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/xapool/xapool/src/org/enhydra/jdbc/standard/ | $ cat xapool/src/org/enhydra/jdbc/standard/*.java | wc -l | 3107 10. http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/*checkout*/xapool/xapool/test/jotmxapooltest/config/postgres.properties?rev=1.1 11. http://people.redhat.com/~vadimn/scratch/pgsql-jdbc/changelog.html#2002-08-14-16:35 12. Download maxdb-source-7_5_00_18.tgz from http://www.mysql.com/products/maxdb/ http://dev.mysql.com/downloads/maxdb/7.5.00.html http://dev.mysql.com/get/Downloads/MaxDB/7.5.00/maxdb-source-7_5_00_18.tgz/from/pick The source for the JDBC driver is in V75_00_18/MaxDB_ORG/sys/src/jv/sapdbc.src.jar After unjarring, | $ grep -lF XA com/sap/dbtech/jdbcext/*.java | xargs cat | wc -l | 1806 | $ cat com/sap/dbtech/jdbcext/XA*.java | wc -l | 1138
pgsql-jdbc by date: