background image

Outbound Contracts

<< Management Contracts | Common Client Interface >>
<< Management Contracts | Common Client Interface >>

Outbound Contracts

server create and provide needed threads. When the resource adapter is finished with a given
thread, it returns the thread to the application server. The application server manages the
thread: It can return the thread to a pool and reuse it later, or it can destroy the thread. Handling
threads in this manner results in increased application server performance and more efficient
use of resources.
In addition to moving thread management to the application server, the Connector architecture
provides a flexible model for a resource adapter that uses threads:
The requesting thread can choose to block (stop its own execution) until the work thread
completes.
Or the requesting thread can block while it waits to get the thread. When the application
server provides a work thread, the requesting thread and the work thread execute in parallel.
The resource adapter can opt to submit the work for the thread to a queue. The thread
executes the work from the queue at some later point. The resource adapter continues its
own execution from the point it submitted the work to the queue, no matter of when the
thread executes it.
With the latter two approaches, the resource adapter and the thread may execute
simultaneously or independently from each other. For these approaches, the contract specifies a
listener mechanism to notify the resource adapter that the thread has completed its operation.
The resource adapter can also specify the execution context for the thread, and the work
management contract controls the context in which the thread executes.
Outbound Contracts
The Connector architecture defines system-level contracts between an application server and
an EIS that enable outbound connectivity to an EIS: connection management, transaction
management, and security.
The connection management contract supports connection pooling, a technique that enhances
application performance and scalability. Connection pooling is transparent to the application,
which simply obtains a connection to the EIS.
The transaction management contract between the transaction manager and an EIS supports
transactional access to EIS resource managers. This contract lets an application server use a
transaction manager to manage transactions across multiple resource managers. This contract
also supports transactions that are managed inside an EIS resource manager without the
necessity of involving an external transaction manager. Because of the transaction management
contract, a call to the EIS may be enclosed in an XA transaction (a transaction type defined by
the distributed transaction processing specification created by The Open Group). XA
transactions are global: they can contain calls to multiple EISs, databases, and enterprise bean
business methods. Although often appropriate, XA transactions are not mandatory. Instead, an
application can use local transactions, which are managed by the individual EIS, or it can use no
transactions at all.
Resource Adapter Contracts
The Java EE 5 Tutorial · September 2007
1022