JCA is a standard introduced in J2EE 1.3. JDBC is not being deprecated,
and JDBC 2.0 already has a pooled connection management notions, for
example, the javax.sql.ConnectionEventListener:
ConnectionEventListener
{
public void connectionClosed(ConnectionEvent event)
public void connectionErrorOccurred(ConnectionEvent event)
}
We don't appear to be using any of the JDBC2.0 connection pool interfaces.
Probably because there aren't any 2.0 compliant open source drivers.
The JDBC 3.0 spec defines how the JDBC SPI relates to JCA but it does not
require a JCA implementation.
<jdbc-3.0 pfd3 spec>
Chapter 19 Relationship to Connectors
19.1 System Contracts
The system contracts defined in the Connector specfication describe the
interface
between an application server and one or more resource adapters. This
interface
allows a resource adapter to be bundled in such a way that it can be used by
any
application server that supports the system contracts.
The following standard contracts are defined between an application server
and a
back end system:
- A connection management contract that enables application components to
connect to a back end system.
The connection management contract is equivalent to the services described
by
the JDBC interfaces DataSource and ConnectionPoolDataSource.
- A transaction management contract between the transaction manager and a
back
end system supporting transactional access to its resources.
The transaction contract is equivalent to the services described by the JDBC
interface XADataSource.
- A security contract that enables secure access to a back end system.
The security contract does not have an equivalent in the JDBC API.
Authentication in the JDBC API always consists of providing a user name and
a
password.
The JDBC specification does not make a distinction between its application
programming interface (API) and the SPI. However, a driver can map the JDBC
interfaces in the SPI to the Connector system contracts.
</jdbc-3.0 pfd3 spec>
----- Original Message -----
From: "Guy Rouillier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 05, 2001 11:18 PM
Subject: Re: [JBoss-user] Strange Behavior When DataSource goes down.
> Scott, is JCA a standard extension that vendors must follow in order to
> claim version x.x compliance? I'm wondering how this mechanism will work,
> for example with database connections, if the DBMS vendors don't put the
> necessary logic into the drivers. And what happens is someone just cuts
the
> wire between the JBoss JVM and the DB server? In the case of unexpected
> outages, neither the DB server nor the JVM (i.e, the DB client) would have
> initiated the close connection, but the connection is lost nonetheless.
> Unexpected outages must be detectable. That is why I think a
isConnected()
> method is preferable (obviously, DBMS vendors must agree to implement that
> for it to do any good.)
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
