pool-xa connections with aries transaction jdbc

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

pool-xa connections with aries transaction jdbc

Pablo Gómez Pérez

Hi all!!

I've been having an issue using PAX-JDBC and Aries jdbc

There is a detailed information here:

https://ops4j1.jira.com/browse/PAXJDBC-106


I copy my last comment in the bug here:

"

Ok, I've debugged this in detailed, PAX know I believe it does it right but I see an inconsistency in the aries side.
PAX provides the factory a correc datasource object. However.. in the aries side:

        if ("xa".equals(transaction) || (transactionManager != null && dataSource instanceof XADataSource)) {
            mcf = new XADataSourceMCFFactory();
            if (transaction == null) {
                transaction = "xa";
            }
        } else if (dataSource instanceof DataSource) {
            mcf = new DataSourceMCFFactory();
            if (transaction == null) {
                transaction = transactionManager != null ? "local" : "none";
            }
        } else {
            throw new IllegalArgumentException("dataSource must be of type javax.sql.DataSource/XADataSource");
        }
        mcf.setDataSource(dataSource);
        mcf.setExceptionSorterAsString(exceptionSorter);
        mcf.setUserName(username);
        mcf.setPassword(password);
        mcf.init();
{
    return foo;
}

so basically because noone did use the REcoverableDatasource.java setters to stablish the user and password, the factory information has the wrong info.

Now the question is whether this is a bug in PAX or in aries

in PAX could be solved in the AriesXaPooledDataSoruceFactory.java

    public DataSource createDataSource(Properties props) throws SQLException {
        try {
            XADataSource ds = dsFactory.createXADataSource(getNonPoolProps(props));
            RecoverableDataSource mds = new RecoverableDataSource();
            mds.setDataSource((CommonDataSource) ds);
            mds.setTransactionManager((AriesTransactionManager) tm);
            BeanConfig.configure(mds, getPoolProps(props));
            mds.start();
            return mds;
        }
        catch (Throwable e) {
            LOG.error("Error creating pooled datasource" + e.getMessage(), e);
            if (e instanceof SQLException) {
                throw (SQLException) e;
            }
            else if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            else {
                throw new RuntimeException(e.getMessage(), e);
            }
        }
    }

there it could be solved by doing like this:

@Override
	public DataSource createDataSource(Properties props) throws SQLException {
		try {
			XADataSource ds = dsFactory.createXADataSource(getNonPoolProps(props));
			RecoverableDataSource mds = new RecoverableDataSource();
			mds.setDataSource(ds);
			mds.setUsername(props.get("user").toString());
			mds.setPassword(props.get("password").toString());
			mds.setTransactionManager(tm);
			BeanConfig.configure(mds, getPoolProps(props));
			mds.start();
			return mds;
		} catch (Throwable e) {
			LOG.error("Error creating pooled datasource" + e.getMessage(), e);
			if (e instanceof SQLException) {
				throw (SQLException) e;
			} else if (e instanceof RuntimeException) {
				throw (RuntimeException) e;
			} else {
				throw new RuntimeException(e.getMessage(), e);
			}
		}
	}

But again, I'm not sure who should have the responsability to do this PAX or Aries...I believe aries but this is just my opinion I will contact them in the mailing list, I'm sure perhaps Christian Scheneider should know about this... so we know where exactly this should be fixed

"


I believe this should be fixed in the Aries-jdbc side, in RecoverableDatasource.java if the provided Datasource object has already a user and a password.  Because right now there is the inconsistency that the RecoverableDatasource.java provides empty strings when the DataSource  object does already have the datasource


I'm currently working locally in my computer with that work around I've explained in the PAX Jira until a solution for this is decided


Thanks

Regards



Reply | Threaded
Open this post in threaded view
|

Re: pool-xa connections with aries transaction jdbc

Pablo Gómez Pérez

To rewrite myself,

I mean that the DataSource  object does already have the credentials, so the inconsistency is that the user and password attributes in RecoverableDataSource.java do not match with the user and password that is coming with the DataSource here:

public void setDataSource(CommonDataSource dataSource) {
        this.dataSource = dataSource;
    }

sooo again should be fixed in PAX or in Aries?




On 10/10/2016 11:03 AM, Pablo Gómez Pérez wrote:

Hi all!!

I've been having an issue using PAX-JDBC and Aries jdbc

There is a detailed information here:

https://ops4j1.jira.com/browse/PAXJDBC-106


I copy my last comment in the bug here:

"

Ok, I've debugged this in detailed, PAX know I believe it does it right but I see an inconsistency in the aries side.
PAX provides the factory a correc datasource object. However.. in the aries side:

        if ("xa".equals(transaction) || (transactionManager != null && dataSource instanceof XADataSource)) {
            mcf = new XADataSourceMCFFactory();
            if (transaction == null) {
                transaction = "xa";
            }
        } else if (dataSource instanceof DataSource) {
            mcf = new DataSourceMCFFactory();
            if (transaction == null) {
                transaction = transactionManager != null ? "local" : "none";
            }
        } else {
            throw new IllegalArgumentException("dataSource must be of type javax.sql.DataSource/XADataSource");
        }
        mcf.setDataSource(dataSource);
        mcf.setExceptionSorterAsString(exceptionSorter);
        mcf.setUserName(username);
        mcf.setPassword(password);
        mcf.init();
{
    return foo;
}

so basically because noone did use the REcoverableDatasource.java setters to stablish the user and password, the factory information has the wrong info.

Now the question is whether this is a bug in PAX or in aries

in PAX could be solved in the AriesXaPooledDataSoruceFactory.java

    public DataSource createDataSource(Properties props) throws SQLException {
        try {
            XADataSource ds = dsFactory.createXADataSource(getNonPoolProps(props));
            RecoverableDataSource mds = new RecoverableDataSource();
            mds.setDataSource((CommonDataSource) ds);
            mds.setTransactionManager((AriesTransactionManager) tm);
            BeanConfig.configure(mds, getPoolProps(props));
            mds.start();
            return mds;
        }
        catch (Throwable e) {
            LOG.error("Error creating pooled datasource" + e.getMessage(), e);
            if (e instanceof SQLException) {
                throw (SQLException) e;
            }
            else if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            else {
                throw new RuntimeException(e.getMessage(), e);
            }
        }
    }

there it could be solved by doing like this:

@Override
	public DataSource createDataSource(Properties props) throws SQLException {
		try {
			XADataSource ds = dsFactory.createXADataSource(getNonPoolProps(props));
			RecoverableDataSource mds = new RecoverableDataSource();
			mds.setDataSource(ds);
			mds.setUsername(props.get("user").toString());
			mds.setPassword(props.get("password").toString());
			mds.setTransactionManager(tm);
			BeanConfig.configure(mds, getPoolProps(props));
			mds.start();
			return mds;
		} catch (Throwable e) {
			LOG.error("Error creating pooled datasource" + e.getMessage(), e);
			if (e instanceof SQLException) {
				throw (SQLException) e;
			} else if (e instanceof RuntimeException) {
				throw (RuntimeException) e;
			} else {
				throw new RuntimeException(e.getMessage(), e);
			}
		}
	}

But again, I'm not sure who should have the responsability to do this PAX or Aries...I believe aries but this is just my opinion I will contact them in the mailing list, I'm sure perhaps Christian Scheneider should know about this... so we know where exactly this should be fixed

"


I believe this should be fixed in the Aries-jdbc side, in RecoverableDatasource.java if the provided Datasource object has already a user and a password.  Because right now there is the inconsistency that the RecoverableDatasource.java provides empty strings when the DataSource  object does already have the datasource


I'm currently working locally in my computer with that work around I've explained in the PAX Jira until a solution for this is decided


Thanks

Regards