Unshareable and shareable connections

WebSphere Application Server supports both unshareable and shareable connections. An unshareable connection is not shared with other components in the application. The component using this connection has full control of this connection.

Access to a resource marked as unshareable means that there is a one-to-one relationship between the connection handle a component is using and the physical connection with which the handle is associated. This access implies that every call to the getConnection method returns a connection handle solely for the requesting user. Typically, you must choose unshareable if you might do things to the connection that could result in unexpected behavior occurring in another application that is sharing the connection (for example, unexpectedly changing the isolation level).

Marking a resource as shareable allows for greater scalability. Instead of creating new physical connections on every getConnection() invocation, the physical connection (that is, managed connection) is shared through multiple connection handles, as long as each getConnection request has the same connection properties. However, sharing a connection means that each user must not do anything to the connection that could change its behavior and disrupt a sharing partner (for example, changing the isolation level). The user also cannot code an application that assumes sharing to take place because it is up to the run time to decide whether or not to share a particular connection.

Connection property requirements

To permit sharing of connections used within the same transaction, the following data source properties must be the same:
  • Java Naming and Directory Interface (JNDI) name. While not actually a connection property, this requirement simply means that you can only share connections from the same data source in the same server.
  • Resource authentication
  • In relational databases:
    • Isolation level (corresponds to access intent policies applied to CMP beans)
    • Readonly
    • Catalog
    • TypeMap
Additionally, the following connection factories properties must be the same for the sharing of connections within the same transaction:
  • JNDI name. While not actually a connection property, this requirement simply means that you can only share connections from the same resource adapter in the same server.
  • Resource authentication
In addition, the ConnectionSpec object used to get the connection must also be the same. For more information on sharing a connection with a CMP bean, see Sharing a connection with a CMP bean.
Note: Java Message Service (JMS) connections cannot be shared with non-JMS connections.

JMS connections for the WebSphere MQ JMS Provider cannot be shareable because they are non-transactional, and the Java™ EE Connector Architecture (JCA) specification only allows transactional resources to be shareable. If the res-sharing-scope is set to shareable in a JMS resource reference, the setting will be ignored and unshareable connections will be used. However, JMS sessions for MQ are transactional, and can be shareable. JMS sessions are shareable by default, and APAR PK59605 provides the ability to specify unshareable sessions.

JMS connections for the Default Messaging Provider are different. With the Default Messaging Provider, connections can be shareable. Sessions, on the other hand, are not managed by a connection pool, and therefore cannot be shareable or unshareable.

Sharing a connection with a CMP bean

WebSphere Application Server allows you to share a physical connection among a CMP bean, a BMP bean, and a JDBC application to reduce the resource allocation or deadlock scenarios. There are several ways to ensure that all of these entity beans and the JDBC applications are sharing the same physical connection.
  • Sharing a connection between CMP beans or methods

    When all CMP bean methods use the same access intent, they all share the same physical connection. A different access intent policy triggers the allocation of a different physical connection. For example, a CMP bean has two methods; method 1 is associated with wsPessimisticUpdate intent, whereas method 2 has wsOptimisticUpdate access intent. Method 1 and method 2 cannot share the same physical connection within a transaction. In other words, an XA data source is required to run in a global transaction.

    You can experience some deadlocks from a database if both methods try to access the same table. Therefore, sharing a connection is determined by the access intents that are defined in the CMP methods.

  • Sharing a connection between CMP and BMP beans

    Remember to first verify that the getConnection methods of both the BMP bean and the CMP bean set the same connection properties. To match the authentication type of the CMP bean resource, set the authentication type of the BMP bean resource to container-managed, which is designated in the deployment descriptor as res-auth = Container.

    Additionally, use one of the following options to ensure connection-sharing between the bean types:
  • Sharing a connection between CMP and a JDBC application that is used by a servlet or a session bean

    Determine the isolation level that the access intent uses on a CMP bean method, then use the corresponding isolation level specified on the resource reference to look up a data source and a connection. For more information refer to Access intent isolation levels and update locks and Isolation level and resource reference.

Factors that determine sharing

The listing here is not an exhaustive one. The product might or might not share connections under different circumstances.

Connection sharing violations

There is a new exception, the SharingViolation exception, that the resource adapter can issue whenever an operation violates sharing requirements. Possible violations include changing connection attributes, security settings, or isolation levels, among others. When such a mutable operation is performed against a managed connection, the SharingViolation exception can occur when both of the following conditions are true:
  • The number of connection handles associated with the managed connection is more than one.
  • The managed connection is associated with a transaction, either local or XA.

Both the component and the J2C run time might need to detect this SharingViolation exception, depending on when and how the managed connection becomes unshareable. If the managed connection becomes unshareable because of an operation through the connection handle (for example, you change the isolation level), then the component needs to process the exception. If the managed connection becomes unshareable without being recognized by the application server (due to some component interaction with the connection handle), then the resource adapter can reject the creation of a connection handle by issuing the SharingViolation exception.




Related concepts
Resource adapters
Data sources
Connection pooling
Connection handles
Requirements for setting isolation level
Related tasks
Using the transaction service
Related reference
Extensions to data access APIs
Connection considerations when migrating servlets, JavaServer Pages, or enterprise session beans
Access intent and isolation level
Access intent policies
Concept topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 11:08:29 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=conshrnon
File name: cdat_conshrnon.html