Hi there,

we have the following problem using a DB2 version 7 on z/OS, referring
also <a
href="http://groups.google.de/group/comp.databases.ibm-db2/browse_thread/thread/2555018c0d364314/ea946c98e25ce4b7?lnk=gst&q=assmann&rnum=2#ea946c98 e25ce4b7">this
thread</a>:

Using a java program with a connection to a DB2 using a type 2-driver,
we insert many datasets into the database in one transaction. The type
2-driver connects to the database using RRSAF. If the program will be
killed (e.g. by using a kill -9 command), the program itself terminats
- but the transaction will be committed. Important is, that the program
did not send any commit command using the jdbc-connection (which cannot
be done by the program because it was killed toughly so the code
sending a rollback or commit will not be reached).

If we use a type 4-driver (which does not connect to the database using
RRSAF), everything works well. The connection will be closed doing a
rollback before. Unfortunately, it is necessary for us to use a type
2-driver, the explanation of this should not be part of this thread and
should not be discussed.

Does anyone has an idea how to solve this problem, doing a implicit
rollback closing a connection? Is there a parameter on the DB2 using
RRSAF where could be set that the database has to do a rollback while
closing a connection? A commit should only be done if the program
explicitly sends the commit-command, not at any time an implicit
commit.

We are looking forward to hearing from you soon.

Best regards,


Ralf

Is there noone having an idea how to solve this problem?

Ralf

Ralf Assmann wrote:

Hi there,
>
we have the following problem using a DB2 version 7 on z/OS, referring
also <a
>

href="http://groups.google.de/group/comp.databases.ibm-db2/browse_thread/thread/2555018c0d364314/ea946c98e25ce4b7?lnk=gst&q=assmann&rnum=2#ea946c98 e25ce4b7">this

thread</a>:
>
Using a java program with a connection to a DB2 using a type 2-driver,
we insert many datasets into the database in one transaction. The type
2-driver connects to the database using RRSAF. If the program will be
killed (e.g. by using a kill -9 command), the program itself terminats
- but the transaction will be committed. Important is, that the program
did not send any commit command using the jdbc-connection (which cannot
be done by the program because it was killed toughly so the code
sending a rollback or commit will not be reached).
>
If we use a type 4-driver (which does not connect to the database using
RRSAF), everything works well. The connection will be closed doing a
rollback before. Unfortunately, it is necessary for us to use a type
2-driver, the explanation of this should not be part of this thread and
should not be discussed.
>
Does anyone has an idea how to solve this problem, doing a implicit
rollback closing a connection? Is there a parameter on the DB2 using
RRSAF where could be set that the database has to do a rollback while
closing a connection? A commit should only be done if the program
explicitly sends the commit-command, not at any time an implicit
commit.

As far as I know, that's working as designed - by the Java folks. They want
to have an implicit commit at application termination/connection close.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

On Nov 21, 6:07 am, Knut Stolze <sto...@de.ibm.comwrote:

Ralf Assmann wrote:
As far as I know, that's working as designed - by the Java folks. They want
to have an implicit commit at application termination/connection close.
>

No, it's not the Java folks, because the same Java folks made the
type-4
driver which works differently. Killing the client absolves it of any
ability
or responsibility to change the subsequent reaction of the DBMS. I
think there must be an option with the RRSAF protocol which by default
deems that a lost connection means commit, and that if the type-2
driver
is written well, there may be a connection property you can set to
alter
this behavior. The type-2 driver is broken if it is as you say. If the
client
is killed when it has done half it's intended transaction, you do *not*
want
the DBMS doing a heuristic commit.

Joe Weinstein at BEA Systems