On 07/28/2010 09:31 AM, Justin Edelson wrote: > 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. >
How service client should know if connections are pooled or not? I don't think that should be left to the implementation. That's a big difference when connections are pooled and when they are not, since that affects does client needs it's own pool implementation or not. So, current spec does not answer should the client have it's own pool or not if it wants pooled connections. >> 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. > There is no pool behind the ConnectionPoolDataSource. As I understand from its Javadoc it always creates a new physical connection that in turn can be pooled (by client of the ConnectionPoolDataSource which is typically an application server implementing the pool). That's why those properties do not make sense for ConnectionPoolDataSource. >> 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." > I think that should be clearly specified how client could distinguish between DataSource returned pooled connections and non-pooled. See above. > 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." > Look, the ConnectionPoolDataSource is used in the following scenario: Client -- uses --> DataSource -- implemented by --> Connection Pool -- uses --> ConnectionPoolDataSource. The JDBC_INITIAL_POOL_SIZE, JDBC_MAX_IDLE_TIME, MAX_POOL_SIZE do make sense for the connection pool implementation, but they do not make sense for ConnectionPoolDataSource. The ConnectionPoolDataSource does not contain any pool implementation (it is used by the application server to implement a pool). They make sense for the DataSource, though, because DataSource can have a pool behind the scene. > 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 > > -- WBR, Ivan S. Dubrov _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
