ClientDataSource40 is a simple data source implementation
that can be used for establishing connections in a
non-pooling, non-distributed environment.
The class ClientConnectionPoolDataSource40 can be used in a connection pooling environment,
and the class ClientXADataSource40 can be used in a distributed, and pooling
environment. Use these DataSources if your application runs under
JDBC4.0. Use the corresponding ClientDataSource, ClientConnectionPoolDataSource, and
ClientXADataSource classes if
your application runs in the following environments:
JDBC 3.0 - Java 2 - JDK 1.4, J2SE 5.0
JDBC 2.0 - Java 2 - JDK 1.2,1.3
The example below registers a DNC data source object with a JNDI naming service.
org.apache.derby.client.ClientDataSource40 dataSource = new org.apache.derby.client.ClientDataSource40 ();
javax.naming.Context context = new javax.naming.InitialContext();
context.bind ("jdbc/my_datasource_name", dataSource);
The first line of code in the example creates a data source object.
The next two lines initialize the data source's
properties. Then a Java object that references the initial JNDI naming
context is created by calling the
InitialContext() constructor, which is provided by JNDI.
System properties (not shown) are used to tell JNDI the
service provider to use. The JNDI name space is hierarchical,
similar to the directory structure of many file
systems. The data source object is bound to a logical JNDI name
by calling Context.bind(). In this case the JNDI name
identifies a subcontext, "jdbc", of the root naming context
and a logical name, "my_datasource_name", within the jdbc
subcontext. This is all of the code required to deploy
a data source object within JNDI. This example is provided
mainly for illustrative purposes. We expect that developers
or system administrators will normally use a GUI tool to
deploy a data source object.
Once a data source has been registered with JNDI,
it can then be used by a JDBC application, as is shown in the
The first line in the example creates a Java object
that references the initial JNDI naming context. Next, the
initial naming context is used to do a lookup operation
using the logical name of the data source. The
Context.lookup() method returns a reference to a Java Object,
which is narrowed to a javax.sql.DataSource object. In
the last line, the DataSource.getConnection() method
is called to produce a database connection.
This simple data source subclass of ClientBaseDataSource maintains
it's own private password property.
The specified password, along with the user, is validated by DERBY.
This property can be overwritten by specifing
the password parameter on the DataSource.getConnection() method call.
This password property is not declared transient, and therefore
may be serialized to a file in clear-text, or stored
to a JNDI server in clear-text when the data source is saved.
Care must taken by the user to prevent security