Ability to set concurrentAccessResolution when methods executeBatch() and executeQuery() are invoked from java.sql.Statement

Our database configuration has CUR_COMMIT = AVAILABLE.

With this setting, you need to explicitly request for currently committed behavior to see the results that are currently committed.

When using the IBM Data Server Driver for JDBC and SQLJ, this is done by setting the property concurrentAccessResolution to CONCURRENTACCESS_USE_CURRENTLY_COMMITTED (1).

We want to get currently committed results from certain java applications accessing through the IBM Data Server Driver for JDBC and SQLJ.

In our code, we use java.sql.Statement.executeBatch to submit a number of different statements to the database for execution, for example:
- Create DGTT
- Create index on the DGTT
- INSERT INTO session.dgtt_table SELECT FROM table ...
- etc
all within the same executeBatch().
In this case, however, setting concurrentAccessResolution to CONCURRENTACCESS_USE_CURRENTLY_COMMITTED (1) doesn't work.

We opened a PMR in which support explained us that the current behavior (not properly documented, but confirmed via PMR) is that, in order for the concurrentAccessResolution request to be sent to the database server, the statement has to be prepared beforehand.
The problem is that this can't be done when, as previously explained, the batch consists of a number of different statements.
As a result, the "INSERT INTO ... SELECT" in the example above will not benefit from the CC.

The enhancement request is a code change to allow executeBatch (as well as executeQuery) to be sent with the option "USE CURRENTLY COMMITTED" when the statement is not prepared.

Perhaps, the problem is related to the INSERT INTO ... SELECT construction. We have probed that any other SQL sentence with java.sql.Statement would be benefit from the CC.