Use of unshareable connections leads to "Cannot use resource in unshareable scope"

[glassfishrobot]

Suppose we have an application with only one servlet using one resource with res-sharing-scope set to Unshareable.

The resource manager is not XA-compliant.

When the servlet makes a getConnection() on the resource manager (retrieved through a JNDI look-up), an exception is raised with the following message "Cannot use resource in unshareable scope".

Note that if the resource manager is XA compliant, there is no problem and a connection is provided to the servlet.

Environment

Operating System: All Platform: Sun

Affected Versions

[9.1peur2]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/7249
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @h2002044
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented vkoniecz@java.net said: The stack trace outside the application scope: GRAVE: StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception java.sql.SQLException: Cannot use resource in unshareable scope at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:115) [...]

[glassfishrobot]

@glassfishrobot Commented vkoniecz@java.net said: Suppose that this only servlet makes use of a second resource with a XA compliant resource manager.

R1 => non XA compliant resource manager (sharing scope = unshareable) R2 => XA compliant resource manager

Two cases: C1) if R1.getConnection() is called before R2.getConnection(), we got the same message: "Cannot use resource in unshareable scope"

C2) if R2.getConnection() is called before R1.getConnection(), there is no problem

It looks like the unshareable sharing scope is allowed in a global transaction (started by the getConnection() on the XA compliant RM). But when the transaction seems "local", it is not.

This looks like a violation of the J2EE standards: 1) Nothing is said about an unshareable scope forbidden for a local transaction 2) A local transaction management must not have any impact on an application 3) When the second getConnection() occurs, the local transaction should be "transformed" into a global transaction and therefore the case C1) should be treated as case C1).

Therefore I change the priority to P1.

[glassfishrobot]

@glassfishrobot Commented @h2002044 said: This is not a bug. This is the expected behavior. For more information on connection sharing, refer : http://blogs.sun.com/JagadishPrasath/entry/connectionsharinginglassfish

When a resource is non-xa, you cannot have multiple resources from same resource-manager/datasource taking part in the same transaction as transaction atomicity cannot be met.

From the above blog, you can see that same physical connection will be shared for multiple "nonXADataSource.getConnection()" calls within a transaction.

Also, it does not have relation to the order of connection acquisition when multiple resource types are involved.

whether

start tx xads.getConnection() nonxads.getConnection() end tx

or start tx nonxads.getConnection() xads.getConnection() end tx

Please provide a test-case if you are able to see the change in behavior if the order is changed.

Changing the priority as this is the expected behavior [not allowing multiple non-xa connections in a transaction]

[glassfishrobot]

@glassfishrobot Commented vkoniecz@java.net said: Please note that the very first problem mentionned involves one and only one resource manager failing on its first getConnection() call.

This is not about two resources (or resource managers) but only one precisely on the very first getConnection(). At that point, I am not even speaking about a second connection. There is no sharing involved at that point !

Your comment "When a resource is non-xa, you cannot have multiple resources from same resource-manager/datasource taking part in the same transaction"

So to begin with, what about the case where we have one and only one resource ?

So the test case is as simple as described in the first comment:

• one non-XA resource manager referenced with the Unshareable scope
• one servlet which looks up to the resource and then calls getConnection() once and only once

[glassfishrobot]

@glassfishrobot Commented vkoniecz@java.net said: Created an attachment (id=2485) Test Case for reproduction

[glassfishrobot]

@glassfishrobot Commented vkoniecz@java.net said: See README.txt provided within the EAR for more details about how to setup the testcase for reproduction.

Case 1): Look at this more like a convenience when no utx is involved so that the same EAR can be deployed on application servers from different vendors

Case 2): The resource reference in the EAR provided are configured so that retrieving a shareable connection will raise an exception as if it is unshareable. Always reproduced ...

[glassfishrobot]

@glassfishrobot Commented @h2002044 said: this is as per design. We do not allow non-shareable connections (even one) for non-xa resource. The design is to fail eagerly. Hence changing this as RFE.

[glassfishrobot]

@glassfishrobot Commented @h2002044 said: FIX INFORMATION :

svn log -v -r 35119

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=17652

Provided a fix such that one non-xa resource will be provided to requesting applications when unshareable is set. If more than one connection (local-tx, unshareable) is requested, an exception will be thrown.

Also added test-case to glassfish/appserv-tests/devtests/jdbc/markconnectionasbad.local (test5)

[glassfishrobot]

@glassfishrobot Commented File: Issue_7249.ear Attached By: vkoniecz@java.net

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-7249

[glassfishrobot]

@glassfishrobot Commented Reported by vkoniecz@java.net

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Thursday, May 20th 2010, 3:48:38 pm