How to use a JCA connection in your application to achieve scalability

Brief introduction

Connection management architectures for relationship and process access to enterprise information Systems (EIS) are based on the Java EE Connector Architecture (JCA) specification. Connection Manager (CM) manages connections from a single application server to manage connections from resource adapters defined through the JCA specification, as well as to manage connections to data sources defined through the Java database connection (JDBC) specification. IBM WebSphere Application Server enables administrators to establish a backend connection pool to share applications on an application server. Connection pooling improves application response time because the overhead of creating new connections for each new request to access the backend resource is avoided.

Optimal connection Use

Typically, application components look for a connection factory in the JNDI (Java naming and directory Interface,java naming and Catalog interface) namespace, and then use that connection factory to get a connection to the underlying EIS. Use these connections carefully to avoid the connection being depleted and to help the application expand.

The following precautions must be taken to achieve optimal connection use:

Explicitly close the connection now

The application component invokes the Getconnection method on the connection factory to obtain an EIS connection. The returned connection instance represents an application-level handle to the underlying physical connection. After the application component completes the use of this connection, you should close the connection using the Close method on the connection interface. If an application component does not close an assigned connection after use, the connection can only be shut down by the application server at a later time when the transaction is cleaned up. This rejects other requests for the connection, limiting scalability.

It is recommended that the application component explicitly close the handle when the connection handle is already in use and is no longer needed. This reduces the likelihood of connection leaks and enhances the ability of the application server to join the physical connection of the EIS into the pool.

Shared Connections and Localtransactioncontainment

Connections in the WebSphere application Server are shared by default. Using a shareable connection means that, if conditions permit, different getconnection () requests for the application actually receive a handle that connects with the same physical connection as the resource. For shared connections, the shared scope is a transaction. Applications that operate outside of global transactions need to use a default context called Localtransactioncontainment (LTC) in the WebSphere application Server.

A shared connection can be used for requests from other transactions only after the Localtransactioncontainment is finished. So it's always wise not to use long-running and nested localtranactioncontainment, these localtranactioncontainment hold shared connections for a long time and cause the connection pool to run out.

Application components can control transaction boundaries and avoid long-running LTC by using the JTA UserTransaction interface or the transaction division API that is specific to an EIS.

Long-running queries

A slow-running query will have a database connection, and the connection cannot be used for any new requests that attempt to access the same resources. A connection can handle only one operation at any time; for example, if one query is 10 seconds, another request for the same resource will be blocked from exploiting the connection. In addition, a slow-running query combined with a higher workload can eventually result in a connection pool being depleted. It may be helpful to continuously monitor usetime and other statistics by enabling connection pooling statistics in performance monitoring infrastructure.

Non-shared connections

Access to resources that are marked as not shared means that a connection handle used by one component has a one-to-one relationship with the physical connection that the handle is associated with. This access implies that each call to the Getconnection method returns only one connection handle to the requesting user. Typically, if you perform an action on a connection that might cause unexpected behavior in another application that shares the connection, you must choose not to share.

Selecting a unshared connection may increase the number of connections used, resulting in the exhaustion of the connection pool on a higher load because a new connection is used for each request.

Autocommit and Localtransactioncontainment

When a connection is in autocommit mode, the operation on that connection is automatically committed after it is executed. If multiple interactions must be grouped into a single transaction (whether local or XA) and committed or rolled back as a unit, autocommit mode closes.

For connections that are used outside of a transaction, the autocommit mode should be set to true,localtransactioncontainment to be activated. When using a unshared connection, if the application sets Autocommit to False, the connection cannot be used for other requests, even when the application closes the connection. Before closing a connection, the application must explicitly invoke the Submit method on the Connection object.

Transaction isolation and read-only properties

If an application changes the transaction isolation level or the read-only property, the system provides a new connection to the application, rather than providing the same shared connection, even in the same transaction. If you change the transaction isolation level frequently from your application, you will get different connections and increase the number of connections you need, eventually causing the connection pool to run out.

Subject

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/

The same principal indicates that a relational database needs to use the same user and password. If the application uses a different user ID and password to get the connection, the physical connection returned by the getconnection call will be different. When the application's Resource authentication settings are set to application, you can use getconnection () or getconnection (string userid, string password) to get the connection. The connection obtained from these two calls is not shared, even though the authentication alias that is administered by the component associated with the database has the same user ID and password used in getconnection (string userid, String password).

Non-shared JMS sessions

JMS connections for JMS providers are not sharable because they are non-transactional, and the Java EE Connector Architecture (JCA) specification allows only transactional resources to be shared. If the Res-sharing-scope in the JMS resource reference is set to shareable, the setting is ignored and a connection is used that is not shared. However, JMS sessions are transactional and shareable. JMS transactions are shareable by default.

When a shareable JMS session joins a transaction, closing the session does not release it to the pool. However, closing the connection makes the connection available to other applications. Next, when a connection is requested by the same application, it may get a new connection in some instances where the application creates a session, and then it creates one.

In these scenarios, you can set the session to be unshared as soon as it is released to the pool after the session is closed. This means that whenever an application invokes Session.close (), the JMS session is automatically freed from any associated transactions and returned to the session pool. Before you can set up a session to be unshared, you need to properly confirm the above scenario and learn about other effects.

Conclusion

Applications play a very important role in the use of a connection in a join pool in the best possible way, using the JCA connection. Follow some usage patterns and have knowledge of connection behavior that can help you avoid running out of connection pools and help improve scalability.