[JDBC] service spec issues about design HOT 2 OPEN

Comment author: Arie van Wijngaarden <[email protected]>

While working with the JDBC service specification, I found the following issues:
Section 125.3.2:

• For creating a DataSource and variants it is possible to pass the URL using the property JDBC_URL. However, it is also possible to pass separate values for host, port, protocol, database, etc. This is ambiguous, or a statement must be made what takes precedence.
• The pool parameters JDBC_INITIAL_POOL_SIZE, JDBC_MAX_IDLE_TIME, JDBC_MAX_POOL_SIZE, JDBC_MAX_STATEMENTS, JDBC_MIN_POOL_SIZE apply according to the specification to ConnectionPoolDataSource and XADataSource. However, according to the Java API those data sources do not implement connection pooling at all. They are designed to work with pool managers not provided by the implementation. For those data sources, the pool parameters have actually no use.
• Related to this: connection pooling is an important issue and given the previous remark it is probably the intention to allow service implementers to provide some means for connection pooling. I would suggest to include those parameters for normal DataSources as created with the createDataSource method.
• The parameters passed as properties could get more explanation. Examples: what do the properties JDBC_ROLE_NAME and JDBC_PROPERTY_CYCLE mean? What is the unit of time in which JDBC_MAX_IDLE_TIME should be given?

from design.

Comment author: Ivan Dubrov <[email protected]>

Let me add a few cents here. Here is discussion I initiated on osgi-dev mailing list a time ago: https://mail.osgi.org/pipermail/osgi-dev/2010-July/002568.html

Here is the excerpt of the post (with few edits):

1. Should DataSource returned by DataSourceFactory#createDataSource return DataSource that pools connections or it should return DataSource that will provide "raw" connections (no pooling)?

I think it is crucial for client to know if DataSource returned from createDataSource implements pooling or not. So, there should be either way to force implementation to return DataSource with pooling (or throw an exception) or there should be way for the client to see if returned DataSource implements pooling at all.

The first case is obviously the preferred for client (so they don't need to bring their own pool implementation if they don't want to), but forces the JDBC provider to brings its own.

The second variant is less useful, because it leaves two options: implement client to be flexible about pooling (use its own pool if required), which complicates code or use it's own pool unconditionally (which makes pooling aspect of this specification useless).

2. What does DataSourceFactory#JDBC_INITIAL_POOL_SIZE and
   DataSourceFactory#MAX_POOL_SIZE mean? In my understanding, they only
   make sense if applied to the createDataSource in case it uses connections from pool. Those properties do not make sense for ConnectionPoolDataSource, since ConnectionPoolDataSource should always
   create new physical connections (see PooledConnection).

from design.