Providing services on top of each other makes them loosely-coupled and
thus more general and more roboust.
Mangling different concerns (and DataSourceCreation and Pooling are
different) makes it less flexible and forces more dependencies to users
who simply want a DataSourceFactory. And yes DSF is very basic becuase
it is meant for other modules (e.g. JPA) to build up more complex
modules. Beside this, DSF already supports creating pooled or XA
Data-sources why not using those?
For error reporting: It is good to have options to find out whats wrong,
DeclarativeService already provide you with a good toolset compared to
traditional plain OSGi-Services, but good Logging-Message are of course
always helpfull. Just one note: Having a service with unsatisfied
dependecies is not an error per-se but might be intentional or temporary
(e.g. upgrading other services) so logging levels should be good decided!
Am 03.08.2016 11:58, schrieb Christian Schneider:
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
--
--
------------------
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.