Fwd: [JDBC] Fwd: [ADMIN] Confuse about the behaveior of PreparedStatement.executeBatch (jdbc)

Hello,

Can anyone please figure out this ?

Begin forwarded message:

> From: dmp <danap(at)ttc-cmc(dot)net>
> Subject: Re: [JDBC] Fwd: [ADMIN] Confuse about the behaveior of PreparedStatement.executeBatch (jdbc)
> Date: December 15, 2012 12:30:50 AM GMT+08:00
> To: Haifeng Liu <liuhaifeng(at)live(dot)com>, pgsql-jdbc(at)postgresql(dot)org
>
> Hello,
>
> Perhaps you should pose the question to the server mailing list. It seems that
> maybe the sequence is possibly being changed in execution. In a small update,
> 10, the sequence stays intact, but for a larger update the server perhaps is
> optimizing the sequence for execution thereby changing the order. In any case
> you appeared to answer your own question.
>
> http://archives.postgresql.org/pgsql-general/
>
> danap.
>
> Haifeng Liu wrote:
>> example code:
>>
>> Connection conn = getConnection();
>> PreparedStatement pstmt = conn.prepareStatement("insert/update...");
>> for (A a : AList) {
>> pstmt.setParameter(...);
>> pstmt.addBatch();
>> }
>> pstmt.executeBatch();
>>
>> I did a simple test and found that if one of the batch failed, the other update may be execute partially. when I test with 10 updates a batch, none of them are updated, when I test with 1000 updates a batch, about 700+ of them are executed, but the failed update should be the last one, which means 999 executed updates is more reasonable than 700+. But really weird thing is the getUpdateCounts method returns the reasonable information.
>>
>> I don't know what happened inside this driver. Currently I have to setAutoCommit to false and use commit/rollback to achieve my goal.
>>
>>
>> On Dec 14, 2012, at 11:56 PM, dmp<danap(at)ttc-cmc(dot)net> wrote:
>>
>>> Hello,
>>>
>>> Though a simple example of your code would provide a better response
>>> from the mailing list, I will speculate based on the context of the
>>> Java 6 API, statement class and your comments. Yes, the batch appears
>>> to be proceeding.
>