In Java 2 Enterprise Edition (J2EE) 1.3, a new concept of a resource sharing scope has been introduced. A resource sharing scope can be either shareable or unshareable, the default being shareable. If the resource is configured as shareable, applications can share connections to this resource; if the resource is unshareable, connections will not be shared. Of all resources, the datasource is the most widely used. This article focuses on how to use unshareable datasources in WebSphere Application Server (WAS) 5.0.
A resource is configured as shareable by setting <res-sharing-scope> of the deployment descriptor to "Shareable". If a datasource is configured as unshareable in WAS 5.0 by setting <res-sharing-scope> to "Unshareable", every getConnection() call will access a connection handle with a different physical connection, even within the same sharing scope (I will discuss this in greater detail later). There is a one-to-one relationship between the connection handle and the physical connection to the datasource. In other words, there is an exclusive physical connection for each connection handle's use. If a datasource is configured as shareable, multiple getConnection() calls may access different connection handles with the same physical connection to the datasource in the same sharing scope. In other words, these connection handles may share the same physical connection.
There are several reasons for using unshareable connections. The first is to isolate unexpected behavior, for example, when you don't want other Enterprise JavaBeans (EJB) to access an EJB's physical connection, in order to avoid unexpected behavior related to the connection. The second reason is that some applications may need to make changes to connection attributes that are not allowed for shareable connections. One example of these attributes is the readOnly attribute. Other examples include character settings, localization configurations, etc. If applications fall into any of these categories, unshareable connections should be used.
Since all connections are shared in WAS 4.0, some programming models that worked in WAS 4.0 might not work without modification in WAS 5.0 if these applications use unshareable data sources. In this article, I will discuss which models work and which won't work when unshareable data sources are used.
Problems with Unshareable Connections
Before I go into detail about sharing connections, let me first clarify what a sharing boundary is. It's a boundary within which a physical connection can be shared by multiple connection handles. In other words, for two or more connection handles to share the same physical connection, they must be within the same sharing boundary. If getConnection() is called twice using the same datasource within the same sharing boundary and their connection sharing attributes are equal, the two connections are eligible to share one physical connection. Based on the resource sharing scope value, the runtime decides whether or not to share the physical connection.
