On 7/28/10 1:25 AM, Ivan Dubrov wrote: > Hi, > > I have few questions regarding JDBC Service Specification. > > 1) Should DataSource returned by DataSourceFactory#createDataSource > return DataSource that pools connections (let's name it "pooled" > DataSource) or it should return DataSource that will provider "physical" > connections (let's name it "raw" DataSource)? AFAICT, this is left up to the implementation.
> > 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 and answer to the first > question is positive. Those properties do not make sense for > ConnectionPoolDataSource, since ConnectionPoolDataSource should always > create new physical connections (see PooledConnection). These properties can be used to configure the connection pool backing the ConnectionPoolDataSource returned by createConnectionPoolDataSource(). Application code should really never use the ConnectionPoolDataSource/PooledConnection interfaces directly. > > > Should not the DataSourceFactory leave pool features to the separate > bundle/service that will provide "pooled" DataSource on top of the "raw" > DataSource/ConnectionPoolDataSource/Driver/XADataSource returned by the > DataSourceFactory? In that case, properties like JDBC_INITIAL_POOL_SIZE, > JDBC_MAX_IDLE_TIME, MAX_POOL_SIZE do not make sense. > This is certainly allowable under the spec. In which case you would have two DataSourceFactory services (presumably differentiated by some service property), but I don't think it is a matter of "should" or "should not." Even if you had a pooling-specific service, those properties would still be useful when invoking createConnectionPoolDataSource() so I'm not sure what you mean in that they "do not make sense." Implementers are free to ignore those properties; if you wanted to distribute/use a bundle/service which provided a fixed-size connection pool or one that was configured elsewhere (such as a service simply fronting an application server-managed pool), that seems fine. Justin _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
