From: | Quartz <quartz12h(at)yahoo(dot)com> |
---|---|
To: | |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: JDBC gripe list (the autocommit subthread) |
Date: | 2011-03-30 13:49:30 |
Message-ID: | 343012.69342.qm@web33203.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
> Well in the postgresql world every statement is a transaction.
I agree with that. But a batch with autocommit=true is "many" statements, as per the doc.
> That being said the concept of batch processing in postgres is that it
> would be done in a transaction otherwise what is the point ?
If addBatch was not meant to be called when autocommit=true, then it would have thrown an exception. The point is to enable multiple statement in 1 executeBatch call. Just imagine a system that separates who makes statements and who executes them. Like event logging lets say. Meanwhile, there are infinite cases where multiple statements are not (and must not) be in a all-or-nothing transaction. This is why applications choose to set autocommit=true to obtain the batch behavior without a TX. It's in the API for such reasons.
It is just incorrect to consider the batch is 1 transaction when the API clearly exposes the ability to avoid it. As I wrote earlier, calling applications that just pile up updates in a batch not expecting any deadlock due to row locking by each statement, will not work anymore.
The fact the API have autocommit independant from batches means it serve a purpose. I see it. But even if I didn't, the API says so and I can't second guess it.
I know it hurts to learn such truth after such a long delay. You'll get over it! lol! I have found a 4 year old bug lately, in my own code. I know the feeling. But I can't decide to call it a feature...lol
> If you agree with that then in the postgres world it would be natural
> for all of it to fail. At least thats how I would expect postgres to act.
>
> Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Quartz | 2011-03-30 14:04:50 | Re: JDBC gripe list |
Previous Message | Donald Fraser | 2011-03-30 10:06:33 | Re: JDBC gripe list |