Thread: Full XA availability ?
Hi list, Currently, the last JDBC driver is not fully XA compliant as it does not support transaction interleaving and suspend/resume. I can't see on the todo list anything about XA improvement. Is it planned to implement the missing XA features ? Sorry if this question has already been asked but I just can't find where... Regards. -- Xavier Bugaud
On Thu, 9 Feb 2006, Xavier Bugaud wrote: > Currently, the last JDBC driver is not fully XA compliant as it does not > support transaction interleaving and suspend/resume. > > I can't see on the todo list anything about XA improvement. Is it > planned to implement the missing XA features ? It is possible to fake these to some extent in the driver, but we've decided not to do that and wait for full support from the backend. There isn't a whole lot of interest from backend developers to do this though and I don't know of anyone working on it. Their goal was to implement two phase commit, but XA is more than that. I'm not sure they knew this at the time and seemed a little put out when the goalposts were moved after they completed the design and implementation. Kris Jurka
On Thu, 9 Feb 2006, Kris Jurka wrote: > On Thu, 9 Feb 2006, Xavier Bugaud wrote: > >> Currently, the last JDBC driver is not fully XA compliant as it does not >> support transaction interleaving and suspend/resume. >> >> I can't see on the todo list anything about XA improvement. Is it >> planned to implement the missing XA features ? > > It is possible to fake these to some extent in the driver, but we've decided > not to do that and wait for full support from the backend. There isn't a > whole lot of interest from backend developers to do this though and I don't > know of anyone working on it. Their goal was to implement two phase commit, > but XA is more than that. I'm not sure they knew this at the time and seemed > a little put out when the goalposts were moved after they completed the > design and implementation. Many other big JDBC implementations don't support it either, or fake it, or support it only partially. Therefore no transaction coordinator implementation can rely on transaction interleaving or suspend/resume anyway, or at least have to provide a flag to work around it. Therefore there's very little practical value in actually implementing them, beside being able to tick the "fully XA-compliant" checkbox in marketing material. See earlier discussion on the subject: http://archives.postgresql.org/pgsql-jdbc/2005-06/msg00165.php Implementing transaction interleaving and suspend resume would be a very invasive change to the backend. Frankly I doubt it will never be implemented. (BTW: this should be added a FAQ. Preferably with instructions on configuring various application servers to work with our implementation) - Heikki
Hi Heikki, > Many other big JDBC implementations don't support it either, > or fake it, or support it only partially. Therefore no transaction > coordinator implementation can rely on transaction interleaving or > suspend/resume anyway, or at least have to provide a flag to > work around > it. Therefore there's very little practical value in actually > implementing them, beside being able to tick the "fully XA-compliant" > checkbox in marketing material. All the application servers need XA for distributed transactions, so I think there is a huge practical value to be "fully XA compliant". It's a very common practise when using J2EE container managed transactions to suspend the current transaction and start a new one for example. Regards. -- Xavier Bugaud
On Fri, 10 Feb 2006, Xavier Bugaud wrote: >> Many other big JDBC implementations don't support it either, >> or fake it, or support it only partially. Therefore no transaction >> coordinator implementation can rely on transaction interleaving or >> suspend/resume anyway, or at least have to provide a flag to >> work around >> it. Therefore there's very little practical value in actually >> implementing them, beside being able to tick the "fully XA-compliant" >> checkbox in marketing material. > > All the application servers need XA for distributed transactions, so I > think there is a huge practical value to be "fully XA compliant". > It's a very common practise when using J2EE container managed > transactions to suspend the current transaction and start a new one for > example. I believe that's a different suspend/resume you're talking about. Are you thinking of for example an EJB calling another EJB that's running on a different application server, with REQUIRES_NEW transaction attribute? You would indeed suspend and resume the global J2EE transaction, but that doesn't necessarily mean that the application server has to suspend/resume the XAResources involved. Suspending/resuming the global J2EE transaction and suspending/resuming a resource manager are two different things, you can have one without the other. I don't know how the above scenario is actually implemented in typical application servers. Also, some application servers are implemented so that they always issue suspend/resume on the resource manager, even in non-distributed case. See the recent thread on WebLogic & XA driver: http://archives.postgresql.org/pgsql-jdbc/2005-11/msg00214.php There's a patch later in that thread that implements suspend/resume for the simple case, where you suspend one transaction and resume the same transaction later, doing nothing with the connection in between. The patch hasn't made it to CVS yet. - Heikki
On Friday 10 February 2006 09:18, Heikki Linnakangas wrote: > Also, some application servers are implemented so that they always issue > suspend/resume on the resource manager, even in non-distributed case. See > the recent thread on WebLogic & XA driver: > > http://archives.postgresql.org/pgsql-jdbc/2005-11/msg00214.php > > There's a patch later in that thread that implements suspend/resume for > the simple case, where you suspend one transaction and resume the same > transaction later, doing nothing with the connection in between. The patch > hasn't made it to CVS yet. Yeah, I still need to formalize that patch. For the time being we decided not to use XA. JdV!! -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------