Hi sateesh, On 08-03-2010 09:06:55 -0800, sateesh wrote:
Here i am including a Sample test program which i wrote to test the batch Execution
I executed your example here. I noticed the following from the log: TX 1269345025845: exec 0(3751548521200044480, -9164647932261081852, 12, 115, false); exec 0(3751548521200044480, -9164647932261081852, 12, 115, false); exec 0(3751548521200044481, -9164647932261081853, 12, 117, false); RD 1269345025870: read final block: 149 bytes RX 1269345025910: &2 1 -1 !SQLException:assert:INSERT INTO: PRIMARY KEY constraint 'instance_test. uuid_key' violated !current transaction is aborted (please ROLLBACK) What I see here is correct, as the first and second argument are the same, so a rollback is performed.
From the JDBC specification:
Disabling auto-commit allows an application to decide whether or not to commit the transaction in the event that an error occurs and some fo the commands in a batch cannot be processed successfully. For this reason, auto-commit should always be turned off when batch updayes are done. The commit behaviour of executeBatch() is always implementation-defined when an error occurs and auto-commit is true. In MonetDB, each batch execution is a transaction. As such, when one statement in the batch fails, the entire batch is invalidated and rollbacked. The interface should allow you to find the statement in your batch that caused the problem iirc. Hope this helps