Subject | Re: ConnectionPoolDataSource... |
---|---|
Author | Roman Rokytskyy |
Post date | 2002-09-20T13:56:23Z |
Hi,
Am I missing something? As I see from API, ConnectionPoolDataSource
is a source of PooledConnection instances, that in turn can provide
you java.sql.Connection instances. I hardly see any relation between
DataSource and ConnectionPoolDataSource. As fas as I know both are
supposed to be retrieved from JNDI, but it's up to you or application
server what to provide and under what name.
We do not have ConnectionPoolDataSource implementation.
FBSimpleDataSource provides you source of physical connections to
database. This means that simpleDataSource.getConnection() will open
new connection to a database, connection.close() will close that
connection.
FBWrappingDataSource can delay closing physical connection hoping
that somebody will need this connection soon. This is what we mean
saying "connection pooling". It is also possible to specify minimum
and maximum number of open physical connections to a database.
From what you described in your message I conclude that you have some
particular implementation of DataSource interface that is able to
perform JNDI lookup of the ConnectionPoolDataSource implementation
and delegate call getConnection() to this instance. If this is right,
this is just your particular implementation. Both FBSimpleDataSource
and FBWrappingDataSource can be bound in JNDI under any name you
like, and you can lookup them directly. Also you can modify your
DataSource implementation to be able to lookup also instances of
DataSource and delegate getConnection() to DataSource implementation.
If I am wrong in my assumption, please explain your configuration
again providing more details about implementations of DataSource and
ConnectionPoolDataSource objects and some sample code, how you plan
to use it.
We do not plan to implement ConnectionPoolDataSource interface in the
nearest future because most application servers provide this
functionality already. And these application servers use either
java.sql.DriverManager or JCA functionality. Both are implemented.
Best regards,
Roman Rokytskyy
Am I missing something? As I see from API, ConnectionPoolDataSource
is a source of PooledConnection instances, that in turn can provide
you java.sql.Connection instances. I hardly see any relation between
DataSource and ConnectionPoolDataSource. As fas as I know both are
supposed to be retrieved from JNDI, but it's up to you or application
server what to provide and under what name.
We do not have ConnectionPoolDataSource implementation.
FBSimpleDataSource provides you source of physical connections to
database. This means that simpleDataSource.getConnection() will open
new connection to a database, connection.close() will close that
connection.
FBWrappingDataSource can delay closing physical connection hoping
that somebody will need this connection soon. This is what we mean
saying "connection pooling". It is also possible to specify minimum
and maximum number of open physical connections to a database.
From what you described in your message I conclude that you have some
particular implementation of DataSource interface that is able to
perform JNDI lookup of the ConnectionPoolDataSource implementation
and delegate call getConnection() to this instance. If this is right,
this is just your particular implementation. Both FBSimpleDataSource
and FBWrappingDataSource can be bound in JNDI under any name you
like, and you can lookup them directly. Also you can modify your
DataSource implementation to be able to lookup also instances of
DataSource and delegate getConnection() to DataSource implementation.
If I am wrong in my assumption, please explain your configuration
again providing more details about implementations of DataSource and
ConnectionPoolDataSource objects and some sample code, how you plan
to use it.
We do not plan to implement ConnectionPoolDataSource interface in the
nearest future because most application servers provide this
functionality already. And these application servers use either
java.sql.DriverManager or JCA functionality. Both are implemented.
Best regards,
Roman Rokytskyy
--- In Firebird-Java@y..., "Mandip S. Sangha" <mandip@s...> wrote:
> Hi Roman
>
> I have a framework that uses javax.sql.DataSource objects for
getting
> connections to a database. An implementation
> javax.sql.ConnectionPoolDataSource interface is also provided with
the
> framework. I was looking into using this class to create and
maintain a
> connection pool. Without pooling I guess I would be using the
> FBSimpleDataSource class to pass DataSource objects to the
framework.
> Inorder to use the pooling I would have to create an instance
> of ConnectionPoolDataSource class, set my particular database
properties
> and register it with JNDI. Then for a DataSource object to use
this
> pooling facility, I would have to use the setDataSourceName()
method to
> inform the DataSource object of the whereabouts of the
> ConnectionPoolDataSource object registered with JNDI. The
DataSource
> object is itself registered with JNDI and whenever a lookup on the
> DataSource is performed the resulting DataSource object will
retrieve
> connections from the ConnectionPoolDataSource object. Thus making
the
> connection pooling transparent. However, now that you mentioned
the
> FBWrappingDataSource class I think all the above discussion is
probably
> irrelevant since I think this class will have the same effect. Is
this
> true????
>
> Regards
> Mandip
>
>
> Roman Rokytskyy wrote:
>
> >Hi,
> >
> >
> >
> >>Can anyone tell me if there is a class somewhere in the driver
that
> >>implements the DataSource interface and the setDataSourceName
> >>(String name) method????
> >>
> >>
> >
> >there are:
> >
> >org.firebirdsql.jdbc.FBSimpleDataSource - simple implementation
with
> >no connection pooling
> >
> >org.firebirdsql.jdbc.FBWrappingDataSource - DataSource
implementation
> >with built-in connection pooling.
> >
> >However, none of them have setDataSourceName(String) method. What
it
> >is supposed to do?
> >
> >Best regards,
> >Roman Rokytskyy
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> >Firebird-Java-unsubscribe@y...
> >
> >
> >
> >Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
> >