You correctly observed that the pooling solutions all offer a DataSource
to the outside.
This is not a shortcomming. It is exactly meant to be this way. The
specs around jta and jpa
mention that the XADataSource is to be used by the container (or in our
case the pooling) and not by the user.
The XA capable pooling solutions work with the XADataSource internally
and offer a DataSource
to the outside. The idea behind this is that when you create a
connection on the DataSource the
pooling/XA solution registers the connection as an XA resource with the
TransactionManager. So it will
automatically take part in the XA transactions.
In servicemix you can leverage pax-jdbc to create a pooling/XA enabled
DataSource. It uses dbcp2 or aries-transaction for the pooling/XA support.
See
https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+for+DataSourceFactory
The current version is a bit broken regarding XA support but the
upcoming version 0.5.0 should work fine.
Christian
Am 09.02.2015 um 06:21 schrieb kb:
Hi,
I noticed that any working servicemix example demonstrating distributed/XA
transactions uses the native XA data-source provided in the database vendor
drivers. On the other side, I couldn't find any 3rd party software providing
xa-connection pooling (Atomikos is often mentionned here as an pooled
XA-datasource candidate, but Atomikos main class AtomikosDataSourceBean only
provides a regular DataSource, not an XA-DataSource and, as-such, requires
Atomikos custom transaction manager installation to properly handle
distributed transactions). The fact that most of those native XA
data-sources are not backed by a connection pool, seems to imply that
Servicemix can freewheelingly open as many connections as it wants against
the database with no upper limit (I'm specifically worrying here about a
"split" pattern gone wrong and trying to open one connection after the
other).
I normally connect to databases through connection pools like commons-dbcp
and c3p0 which I use as "circuit-breakers" to prevent that one of my
applications unwillingly throws a denial-of-request attack on the database
by exhausting all database connections.
Is there any way to mitigate this problem or is that issue of no concern ?
(if so, then why ?)
Regards
kb
--
View this message in context:
http://servicemix.396122.n5.nabble.com/Are-XA-datasources-dangerous-tp5722254.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com