Patterns: Implementing Self-Service in an SOA Environment

444 Patterns: Implementing Self-Service in an SOA Environment

If the connection timeout is set to a very small number such as 1, the

ResourceAllocationException is thrown almost immediately after the pool

manager determines that the maximum number of connections has been

used. If the connection timeout is set to 0, the pool manager waits until a

connection can be allocated. In other words, it waits until the number of

connections falls below the maximum connections.

򐂰 Maximum connections

This is the maximum number of managed connections that can be created by

a particular ManagedConnectionFactory. After this number is reached, no

new connections are created, and either the requester waits or the

ResourceAllocationException is thrown. If maximum connections is set to 0,

the number of connections can grow indefinitely. Maximum connections must

be larger than minimum connections.

򐂰 Minimum connections

The minimum number of managed connections to maintain. If this number is

reached, the garbage collector will not discard any managed connections.

Note that if the actual number of connections is lower than the value specified

by the minimum connections settings, no attempt will be made to increase the

number of connections to the minimum. Minimum connections must be less

than or equal to maximum connections.

򐂰 Reap time

This is the number of seconds between runs of the garbage collector. The

garbage collector discards all connections that have been unused for the

value specified by the unused timeout.

To disable the garbage collector, set the reap time to 0. Another way to

disable the garbage collector is to set the unused timeout to 0.

򐂰 Unused timeout

Number of milliseconds after which an unused connection is discarded.

Setting this value to 0 disables the garbage collector.

12.6.3 Scalability and availability considerations

As shown in Figure 12-33 on page 445, there are several scalability and

availability options when using J2EE connectors to access CICS enterprise

applications:

򐂰 EJB workload management provided by WebSphere Application Server.

򐂰 Inbound CICS TG requests (TCP or HTTP) can be workload managed using

various methods.

Chapter 12. J2EE Connector Architecture scenario 445

򐂰 CICS requests (ECI or EPI) can be workload managed using CICS scalability

technologies.

Figure 12-33 Scalability options

EJB workload management

EJBs deployed in WebSphere Application Server V6 can take advantage of the

workload management (WLM) facility for EJBs. In WebSphere Application

Server, workload management for EJBs is enabled automatically when clusters

are created in a cell. There is no need for a special configuration to enable it.

Workload management of CICS TG requests

This section describes scalability and availability options between EJBs in a

distributed environment (Windows or UNIX) and the CICS TG in a zSeries®

environment. An ECI request from a J2EE connector resource adapter goes to

the CICS TG on zSeries as an HTTP or TCP request.

Web

Browser

Servl et

CICS ECI

Resource

Adapter

EJB

CICS ECI

Resource

Adapter

EJB

CICS ECI

Resource

Adapter

EJB

:

CI CS

Transaction

Gat ewa y

CICS

Transaction

Gat eway

CICS

Transaction

Gat eway

:

CICS TS

CI CS

Progr am

(ITSOMART)

CICS TS

CI CS

Progr am

(ITSOMART)

CICS TS

CI CS

Progr am

(ITSOMART)

:

RMI/IIOP

TCP/HTTP EXCI/ MRO

1 2 32

JSP