Scribd
Upload
34 views3 pages

Javax

The document summarizes the javax.sql package, which provides an API for server-side data source access and processing from Java. It introduces key interfaces like DataSource for establishing database connections, and describes how connection pooling and distributed transactions are supported transparently when using a DataSource. Rowsets are also covered, including how a RowSetReader populates a disconnected RowSet from a data source, and how a RowSetWriter synchronizes changes back to the source.

Uploaded by

GitikaBansal
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
34 views3 pages

Javax

The document summarizes the javax.sql package, which provides an API for server-side data source access and processing from Java. It introduces key interfaces like DataSource for establishing database connections, and describes how connection pooling and distributed transactions are supported transparently when using a DataSource. Rowsets are also covered, including how a RowSetReader populates a disconnected RowSet from a data source, and how a RowSetWriter synchronizes changes back to the source.

Uploaded by

GitikaBansal
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Package javax.

sql
Provides the API for server side data source access and processing from the JavaTM programming
language.
Package javax.sql Description

Provides the API for server side data source access and processing from the JavaTM programming
language. This package supplements the java.sql package and, as of the version 1.4 release, is included
in the JavaTM 2 SDK, Standard Edition. It remains an essential part of the Java 2 SDK, Enterprise Edition
(J2EE).

The javax.sql package provides for the following:


 The DataSource interface as an alternative to the DriverManager for establishing a connection
with a data source
 Connection pooling
 Distributed transactions
 Rowsets

Applications use the DataSource and RowSet APIs directly, but the connection pooling and distributed
transaction APIs are used internally by the middle-tier infrastructure.

Using a DataSource Object to Make a Connection


The javax.sql package provides the preferred way to make a connection with a data source. The
DriverManager class, the original mechanism, is still valid, and code using it will continue to run.
However, the newer DataSource mechanism is preferred because it offers many advantages over the
DriverManager mechanism.

These are the main advantages of using a DataSource object to make a connection:
 Applications do not need to hard code a driver class.
 Changes can be made to a data source's properties, which means that it is not necessary to
make changes in application code when something about the data source or driver changes.
 Connection pooling and distributed transactions are available through a DataSource object that
is implemented to work with the middle-tier infrastructure. Connections made through the
DriverManager do not have connection pooling or distributed transaction capabilities.

Driver vendors provide DataSource implementations. A particular DataSource object represents a


particular physical data source, and each connection the DataSource object creates is a connection to
that physical data source.

A logical name for the data source is registered with a naming service that uses the Java Naming and
Directory InterfaceTM (JNDI) API, usually by a system administrator or someone performing the duties
of a system administrator. An application can retrieve the DataSource object it wants by doing a lookup
on the logical name that has been registered for it. The application can then use the DataSource object
to create a connection to the physical data source it represents.

A DataSource object can be implemented to work with the middle tier infrastructure so that the
connections it produces will be pooled for reuse. An application that uses such a DataSource
implementation will automatically get a connection that participates in connection pooling. A
DataSource object can also be implemented to work with the middle tier infrastructure so that the
connections it produces can be used for distributed transactions without any special coding.
Connection Pooling
Connections made via a DataSource object that is implemented to work with a middle tier connection
pool manager will participate in connection pooling. This can improve performance dramatically
because creating new connections is very expensive. Connection pooling allows a connection to be used
and reused, thus cutting down substantially on the number of new connections that need to be created.

Connection pooling is totally transparent. It is done automatically in the middle tier of a J2EE
configuration, so from an application's viewpoint, no change in code is required. An application simply
uses the DataSource.getConnection method to get the pooled connection and uses it the same way it
uses any Connection object.

The classes and interfaces used for connection pooling are:


 ConnectionPoolDataSource
 PooledConnection
 ConnectionEvent
 ConnectionEventListener
The connection pool manager, a facility in the middle tier of a three-tier architecture, uses these classes
and interfaces behind the scenes. When a ConnectionPoolDataSource object is called on to create a
PooledConnection object, the connection pool manager will register as a ConnectionEventListener
object with the new PooledConnection object. When the connection is closed or there is an error, the
connection pool manager (being a listener) gets a notification that includes a ConnectionEvent object.
Distributed Transactions
As with pooled connections, connections made via a DataSource object that is implemented to work
with the middle tier infrastructure may participate in distributed transactions. This gives an application
the ability to involve data sources on multiple servers in a single transaction.

The classes and interfaces used for distributed transactions are:


 XADataSource
 XAConnection
These interfaces are used by the transaction manager; an application does not use them directly.

The XAConnection interface is derived from the PooledConnection interface, so what applies to a pooled
connection also applies to a connection that is part of a distributed transaction. A transaction manager
in the middle tier handles everything transparently. The only change in application code is that an
application cannot do anything that would interfere with the transaction manager's handling of the
transaction. Specifically, an application cannot call the methods Connection.commit or
Connection.rollback, and it cannot set the connection to be in auto-commit mode (that is, it cannot call
Connection.setAutoCommit(true)).

An application does not need to do anything special to participate in a distributed transaction. It simply
creates connections to the data sources it wants to use via the DataSource.getConnection method, just
as it normally does. The transaction manager manages the transaction behind the scenes. The
XADataSource interface creates XAConnection objects, and each XAConnection object creates an
XAResource object that the transaction manager uses to manage the connection.
Implementations can vary widely, but generally a reader makes a connection to the data source, reads
data from the data source and populates the rowset with it, and closes the connection. A reader may
also update the RowSetMetaData object for its rowset. The rowset's internal state is also updated,
either by the reader or directly by the method RowSet.execute.
RowSetWriter
A disconnected RowSet object that has implemented the RowSetInternal interface can call on its writer
(the RowSetWriter object associated with it) to write changes back to the underlying data source.
Implementations may vary widely, but generally, a writer will do the following:

 Make a connection to the data source


 Check to see whether there is a conflict, that is, whether a value that has been changed in the
rowset has also been changed in the data source
 Write the new values to the data source if there is no conflict
 Close the connection

The RowSet interface may be implemented in any number of ways, and anyone may write an
implementation. Developers are encouraged to use their imaginations in coming up with new ways to
use rowsets.

You might also like