Current design of pax-jdbc-config and pool

The DB driver or a pax-jdbc adapter provide a DataSourceFactory service. This service does not necessarily provide pooling or XA support.

There are several pax-jdbc-pool modules. Each of these tracks the original DataSourceFactory service and installs a pooling as well as XA enabled DataSourceFactory serice on top. These delegate to the original DSF to create the DS and then wrap it with pooling and XA support. the new DSFs are create with the names -pool and -pool-XA attached.

The config support expects the user to install a config for a ManagedServiceFactory that refers to the DSF by name or class with the suffixes attached if pooling and or XA support is desired.

See

https://ops4j1.jira.com/wiki/display/PAXJDBC/Create+DataSource+from+config

https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+for+DataSourceFactory


     Problems

A lot of users struggle with the current design as it is a bit unnatural when learning it and there are lot of things that can go wrong without good error reporting.

So for example when the original DSF is missing then the enhanced DSF will just not be created. If the TransactionManager is missing then the XA enhanced DSF wrapper service is not created.

It is also confusing to have many DSF services if for example the pax-jdbc native adapter as well as the original driver both install a DSF.

If anything is wrong then the DS service is simply not created. As this all uses the whiteboard pattern there is no easy way to give direct feedback as when something is missing it can mean that the setup is wrong but also that maybe the needed services simply have not yet come up.


     Goals

So the goals of a new design are to provide a more natural solution and also provide good error/warning messages if anything is wrong in the system.


     New Design

For the new desgin the main idea is to only have the orignal DSF service and not create additional ones. The pooling and XA support is provided by a new service interface that is only used internally in pax-jdbc and does not have to be visible to the user.

For the configs the idea is to have properties that mark the need for a pool or XA:

If the property pool is present in the config then it means the user wants pooling support. If it is not present then the orignal DSF is used.

pool=[dbcp2,aries,narayana]

If the property xa=true is present then the user wants XA support on top of pooling. XA support without pooling is invalid.

xa=true


The pooling and XA support it implemented in a plugable way by implementing this interface:

package org.ops4j.pax.jdbc.pool.common;

public interface PooledDataSourceFactory {
    DataSource create(DataSourceFactory dsf, Properties config);
}

The impl is published as a service with e.g. pool=aries and xa=true.


     Error reporting

The pax-jdbc-config module will detect any DS config and immediately report that it has detected the config and what it is searching for now.

For example if you give it the config below then it will report that it searches a DSF with the property |osgi.jdbc.driver.name=H2, |aries pooling support and a TransactionManager service.

|osgi.jdbc.driver.name=H2|
|databaseName=||test|
|user=sa|
|password=|
|dataSourceName=test2
pool=aries
xa=true
|
|pool.maxTotal=8|

After a timeout it will warn about which of the above is still missing.

||To further improve the experience we could also hint for ways to fix the problem. Like when you give osgi.jdbc.driver.name=H2 it could report that you should install the pax-jdbc-h2 feature in karaf, pax-jdbc-pool-aries if the aries pooling is missing or the transaction feature if the TransactionManager service is missing. Not sure if we want to be karaf specific here though.

Christian


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--
--
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to