Thread: BUG #5297: Add XATMI C API
The following bug has been logged online: Bug reference: 5297 Logged by: Juergen Weber Email address: weberjn@gmail.com PostgreSQL version: 8 Operating system: Linux Description: Add XATMI C API Details: An XATMI C API should be added to the PostgresQL C client, so one could run XA transactions under control of a TX monitor. An interesting usecase would be to use PostgresQL together with the LGPL open source JBoss Blacktie transaction manager (http://www.jboss.org/blacktie.html)
On 27/01/2010 2:11 AM, Juergen Weber wrote: > > The following bug has been logged online: > > Bug reference: 5297 > Logged by: Juergen Weber > Email address: weberjn@gmail.com > PostgreSQL version: 8 > Operating system: Linux > Description: Add XATMI C API > Details: > > An XATMI C API should be added to the PostgresQL C client, so one could run > XA transactions under control of a TX monitor. An interesting usecase would > be to use PostgresQL together with the LGPL open source JBoss Blacktie > transaction manager (http://www.jboss.org/blacktie.html) Not a bug. You might want to ask on the JDBC list about this. -- Craig Ringer
On Tue, Jan 26, 2010 at 1:11 PM, Juergen Weber <weberjn@gmail.com> wrote: > An XATMI C API should be added to the PostgresQL C client, so one could run > XA transactions under control of a TX monitor. An interesting usecase would > be to use PostgresQL together with the LGPL open source JBoss Blacktie > transaction manager (http://www.jboss.org/blacktie.html) You could submit a patch... or offer to fund a developer... ...Robert
The response to this issue says it is "Not a bug". Would it be possible for someone to provide an indication of how much effort is involved in providing XA support in the C API library (libpq)? <http://www.postgresql.org/docs/current/static/libpq.html>
Michael Musgrove <mmusgrov@redhat.com> writes:
> The response to this issue says it is "Not a bug". Would it be possible
> for someone to provide an indication of how much effort is involved in
> providing XA support in the C API library (libpq)?
What do you consider to be "providing XA support"? XA requires there to
be a transaction manager somewhere, which is not something libpq can
provide since it's dependent on the good graces of its host application.
Maybe there would be some value in teaching libpq to interact with an
external XA manager, but what exactly do you think is required?
regards, tom lane
On 04/21/2011 05:43 PM, Tom Lane wrote: > Michael Musgrove<mmusgrov@redhat.com> writes: >> The response to this issue says it is "Not a bug". Would it be possible >> for someone to provide an indication of how much effort is involved in >> providing XA support in the C API library (libpq)? > What do you consider to be "providing XA support"? XA requires there to > be a transaction manager somewhere, which is not something libpq can > provide since it's dependent on the good graces of its host application. > Maybe there would be some value in teaching libpq to interact with an > external XA manager, but what exactly do you think is required? > > regards, tom lane I am referring to the X/Open specification Distributed Transaction Processing: The XA Specification (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql provides a conforming Resource Manager switch then we can include postgresql work along with interactions with other Resource Managers (Oracle, DB2) in the same transaction. For example the equivalent support in Oracle that I am asking for is documented at http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm Thanks, Mike
On 21.04.2011 20:04, Michael Musgrove wrote: > I am referring to the X/Open specification Distributed Transaction > Processing: The XA Specification > (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql > provides a conforming Resource Manager switch then we can include > postgresql work along with interactions with other Resource Managers > (Oracle, DB2) in the same transaction. For example the equivalent > support in Oracle that I am asking for is documented at > http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm When I wrote the patch for the backend support, I was not able to find any open source implementations of X/Open XA-compatible resource managers or transaction managers, which makes it kind of hard to implement the API correctly. There was plenty of JDBC XA implementations, however, so I used that for testing. If you can find something to test it with, it probably wouldn't be that hard to write the library. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
We would certainly be very interested in testing XA support. Our project is called BlackTie - it's an XATMI implementation. We use the JBossTS transaction manager for the transaction engine - although JBossTS is written in Java, providing XA support was reasonably easy since it conforms to the OTS specification which means we can control transactions from a C based XA environment. There is an example of using different resource managers within transactions: https://svn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp The files ora.c and db2.c show user code accessing resources from two different vendors - the XA specific information is defined in btconfig.xml (basically it just exposes the XA open string, the symbol name of the xa switch structure and the name of the library that exports the switch symbol). > On 21.04.2011 20:04, Michael Musgrove wrote: >> I am referring to the X/Open specification Distributed Transaction >> Processing: The XA Specification >> (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql >> provides a conforming Resource Manager switch then we can include >> postgresql work along with interactions with other Resource Managers >> (Oracle, DB2) in the same transaction. For example the equivalent >> support in Oracle that I am asking for is documented at >> http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm >> > > When I wrote the patch for the backend support, I was not able to find > any open source implementations of X/Open XA-compatible resource > managers or transaction managers, which makes it kind of hard to > implement the API correctly. There was plenty of JDBC XA > implementations, however, so I used that for testing. > > If you can find something to test it with, it probably wouldn't be > that hard to write the library. >
Sorry, the link I included was for committers. Try this instead https://anonsvn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp/ and the project page is http://www.jboss.org/blacktie > We would certainly be very interested in testing XA support. Our > project is called BlackTie - it's an XATMI implementation. We use the > JBossTS transaction manager for the transaction engine - although > JBossTS is written in Java, providing XA support was reasonably easy > since it conforms to the OTS specification which means we can control > transactions from a C based XA environment. > > There is an example of using different resource managers within > transactions: > https://svn.jboss.org/repos/blacktie/trunk/atmibroker-xatmi/src/example/txfooapp > > The files ora.c and db2.c show user code accessing resources from two > different vendors - the XA specific information is defined in > btconfig.xml (basically it just exposes the XA open string, the symbol > name of the xa switch structure and the name of the library that > exports the switch symbol). > >> On 21.04.2011 20:04, Michael Musgrove wrote: >>> I am referring to the X/Open specification Distributed Transaction >>> Processing: The XA Specification >>> (pubs.opengroup.org/onlinepubs/009680699/toc.pdf). If postgresql >>> provides a conforming Resource Manager switch then we can include >>> postgresql work along with interactions with other Resource Managers >>> (Oracle, DB2) in the same transaction. For example the equivalent >>> support in Oracle that I am asking for is documented at >>> http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adga1_xa.htm >>> >> >> When I wrote the patch for the backend support, I was not able to >> find any open source implementations of X/Open XA-compatible resource >> managers or transaction managers, which makes it kind of hard to >> implement the API correctly. There was plenty of JDBC XA >> implementations, however, so I used that for testing. >> >> If you can find something to test it with, it probably wouldn't be >> that hard to write the library. >> >