isolationLevel=TRANSACTION_NONE on dataSource config

[njr-11]

Statement of user story:
"As a user of database connectivity in Liberty, I would like the Liberty dataSource configuration to permit me to configure a default isolation level of TRANSACTION_NONE so that I can use a JDBC driver that does not support transactions while still taking advantage of value added capabilities such as connection pooling and statement caching."

Specifically, this will involve the introduction of an isolationLevel option, TRANSACTION_NONE. It might be necessary to internally use different constant value than the spec one for this because the spec one appears to have been abused for other purposes (means unspecified on resource ref).

When TRANSACTION_NONE is used as the isolation level for a connection, Liberty should not make any attempt to enlist the connection in global transactions, instead considering it similarly to transactional=false path. Should consider rejecting the setAutoCommit(false) operation in case the JDBC driver doesn't.

Tests should ensure that dataSource configured with isolationLevel=TRANSACTION_NONE can be used with or without a resource-ref, that it reports Connection.getTransactionIsolation() as Connection.TRANSACTION_NONE, and that operations made on the connection are not enlisted into a global transaction. For example, if the global transaction surrounding the code block rolls back, updates made using the TRANSACTION_NONE connection are not rolled back.

[gkwan-ibm]

Serviceability Approval Comment - Please answer the following questions for serviceability approval (note that this is a new approval step -- comments welcome on how to improve it):

1. WAD -- does the WAD identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?

2. Test and Demo -- As part of the new serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
   a) What problem paths were tested and demonstrated?
   b) Who did you demo to?
   c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

3. SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered.
   a) Who conducted SVT tests for this feature?
   b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

4. Queues -- Which L2 / L3 queues will handle PMRs for this feature? Do the respective L2 / L3 teams know they are supporting it?

[alexsm82]

Hi @gkwan-ibm. Given this was completed as a story rather than a feature we won't be going through the feature approval process on this item.

[alexsm82]

@marikaj123 adding focalApprovalReady tag on as this story needs FAT approval.

[bsbyrd1]

No ID is required for this feature.

[dave-waddling]

FAT Focal Approval: The Feature Test Summary looks good and the code made it into the SOE over the weekend where it passed across the board. Approval granted.