Jan, can I ask for a clarification please?
It also has its Default run-configuration configured with "-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1".
...but the default value for jbo.doconnectionpooling is false (and it is so in your sample application for both AMs as well).
Assuming you actually meant false, we might need to turn your question on it's head. I would have expected with jbo.doconnectionpooling=false to have meant with the <No Controller Transaction> option you should have instead seen this:
Total Count = 2, Current Capacity = 2, Number Available = *0*, Number Unavailable = *2*
....as the created JDBC connections should be held by the referenced AMs and therefore should be unavailable. So to me this seems in error, not the Use Existing Transaction if Possible option.
I need to run this through the FMW Control performance diagnostics to see what it reports and if this correlates with the WLS console. (Maybe even DMS Spy would help here?) I'm a few days away from doing this due to internal work, if you have time I suggest you investigate further and report back if you can please.
Thanks for your reply Chris.
...but the default value for jbo.doconnectionpooling is false ...
Looks like it could be confusing, but I am talking about the run-configuration named "Default" (by default) which I have configured with Java Options "-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1" (so JVM system properties).
... (and it is so in your sample application for both AMs as well). ...
In the sample application (UnavailableConnApp-v0.01.zip) the configured JVM system properties "-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1" are a (less confusing) alternative for a per Application Module configuration.
... Assuming you actually meant false, ...
So, that is a wrong assumption.
... I would have expected with jbo.doconnectionpooling=false to have meant with the <No Controller Transaction> option you should have instead seen this:
Total Count = 2, Current Capacity = 2, Number Available = *0*, Number Unavailable = *2* ...
Yes, for that configuration, that is indeed the behaviour I see.
So, please reconsider the scenario's (sc1) and (sc2) and the questions (q1) and (q2) taking the above clarification in to account.
- about (q1)
-- In the context of SR 3-7731361361 bug 17378310, "TASK-FLOW TRANSACTION OPTIONS AND UNAVAILABLE CONNECTIONS", has been filed for this.
(Seemingly related (as "connection leak") bug 17405152, "POOLLIMITSQLEXCEPTION AFTER A FEW BROWSER-SESSIONS FROM SUBSEQUENT REQUESTS", was filed in the context of SR 3-7754676151 .)
- about (q2)
-- As a workaround for bug 17378310 we go the suggestion to configure "-Doracle.adfm.useSharedTransactionForFrame=false",
which does not seem to be documented, but was explained as
"In JDev 126.96.36.199.0, framework uses the BC4J shared transaction feature for taskflow transactions. On 188.8.131.52.0 and earlier the framework used to use a shared root AM instead. By setting this property it will be ensured that the transaction taskflow support will start behaving in the way it behaves in 11g Release 1."
This seems to improve the behaviour of scenario (sc2).