| From: | Jeffrey Tenny <jeffrey(dot)tenny(at)comcast(dot)net> |
|---|---|
| To: | pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: "Idle in Transaction" revisited. |
| Date: | 2004-09-18 21:50:59 |
| Message-ID: | 414CADC3.5050907@comcast.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
> John R Pierce <pierce(at)hogranch(dot)com>, pgsql-jdbc(at)postgresql(dot)org
>
> Gaetano Mendola wrote:
>
>> John R Pierce wrote:
>>
>>> I'm curious what common practice is for threads that do nothing
>>> but SELECTS... do folks just enable auto_commit, thereby
>>> preventing pgJDBC from doing BEGIN; ? Do they lace their code
>>> with COMMIT() calls?
>>
>>
>>
>> We were bitten by this problem too, and my solution was to suggest
>> our developer to do and explicit: "ABORT" after the connection, and
>> do explicit "BEGIN" "END" instead of rely on the jdbc interface.
>>
>
>
> This is a pretty bad idea as it can confuse the driver's idea of the
> current transaction state. For example, cursor-based resultsets won't
> ever be used if you do your own transaction demarcation in this way.
>
> Better to use the standard JDBC autocommit API and a driver that has
> the premature-BEGIN problem fixed.
Second that, it's a very bad idea. I once naively had my own transaction
management using begin/end via jdbc for multi-statement transactions
against PostgreSQL.
Then the driver was updated at some point and I was getting all kinds
of screwed up commit logic and inconsistent data models.
Stick with and support the proper JDBC interfaces. Anything else is
platform dependeng, among other bad things.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeffrey Tenny | 2004-09-18 21:59:37 | Re: "Idle in Transaction" revisited. |
| Previous Message | Oliver Jowett | 2004-09-18 21:29:04 | raising the default prepareTheshold |