To commit a unit of work, your JDBC and SQLJ applications can issue JDBC and SQLJ commit and rollback method calls. The DB2® JDBC driver converts these calls into a JCICS commit or a JCICS rollback call, resulting in a CICS syncpoint being taken. A JDBC or SQLJ commit therefore results in the whole CICS unit of work being committed, not just the updates made to DB2. CICS does not support committing work done using a JDBC connection independently of the rest of the CICS unit of work.
A JDBC or SQLJ application can also issue JCICS commit or rollback directly, and this has the same result as issuing a JDBC or SQLJ commit or rollback method call. The whole unit of work is committed or rolled back together, both DB2 updates and updates to CICS controlled resources.
When you are working with JDBC connections, there are some circumstances in which you cannot avoid a syncpoint being taken, and the unit of work being committed, when the connection to the DB2 database is closed. This applies in either of the following circumstances:
For a stand-alone application, these rules do not cause a problem, as CICS ensures that an end of task syncpoint is taken in addition to any syncpoint that is taken when the connection is closed. However, the JDBC and SQLJ application programming interfaces do not support the concept of multiple application programs for each unit of work. If you have a number of programs that make up an application, one program might access DB2, then call another program that also accesses DB2, in the course of a single unit of work. If you want these programs to be Java™ programs that use JDBC or SQLJ, you need to ensure that the unit of work is not committed when the connection to DB2 is closed, or else the application will not operate as planned. You should be particularly aware of this requirement if you are replacing programs in an existing application with Java programs that use JDBC or SQLJ, and you want to share the same CICS-DB2 thread between the programs. Using a default URL to acquire the connection, rather than an explicit URL, addresses this issue (see Syncpoint issues for explicit and default URLs).
JDBC applications can use the autocommit property of a JDBC connection. The autocommit property causes a commit after each update to DB2. This commit is a CICS commit, and results in the whole unit of work being committed.
Using the autocommit property also causes a commit to be taken when a connection is closed, both for connections obtained using an explicit URL, and connections obtained using a default URL.
The use of autocommit in a CICS environment is not recommended, and for this reason the DB2 JDBC driver sets a default of autocommit(false) when running in a CICS environment, which differs from non-CICS environments where the default is autocommit(true).
Autocommit(true) must not be used in an enterprise bean running as part of an OTS transaction. This causes an ASPD abend, because it causes a CICS syncpoint to be taken, which is not allowed in an OTS transaction.
When a Java application for CICS that uses JDBC or SQLJ acquires a connection using an explicit URL, it operates in an environment similar to that of a DPL server program linked to with the SYNCONRETURN attribute. When the application program closes the explicit URL connection:
So with all levels of the JDBC driver, when the application program closes an explicit URL connection, that is the end of the unit of work.
You can overcome this restriction by acquiring the connection using a default URL instead of an explicit URL, or by using a DataSource that provides a default URL connection (see Acquiring a connection to a database). When a default URL is used, the Java application does not have to close the connection on a unit of work boundary, and no syncpoint is taken when the connection is closed (provided that autocommit(true) has not been specified).
It is recommended that you always use default URL connections in a CICS environment.