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: | Raw Message | Whole Thread | 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 |