Re: commit problem

So ... looking at the API this is clearly unambiguous. A rarity in JDBC

from the api specs ...

void commit()
throws SQLException
Makes all changes made since the previous commit/rollback permanent
and releases any database locks currently held by this Connection
object. This method should be used only when auto-commit mode has been
disabled.
Throws:
SQLException - if a database access error occurs, this method is
called while participating in a distributed transaction, if this
method is called on a closed conection or this Connection object is in
auto-commit mode
See Also:
setAutoCommit(boolean)

So it would appear oracle is breaking their own API.

Thoughts ?

<tongue in cheek>
BTW, you might suggest to your Oracle centric dev that he pay the
difference for the licenses if he really wants Oracle
</tongue in cheek>

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Thu, Oct 25, 2012 at 4:12 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> my Java developers are telling me, the recent JDBC drivers are throwing an
> exception if they inadvertantly issue a commit() on an autocommit
> connection. this is causing a bunch of problems for us, we have a huge
> code base of java jdbc software which was originally written for Oracle, and
> it assumes that read only operations are NOT starting a transaction block
> (apparently Oracle only starts a transaction block on DML like
> insert/update/delete/select for update/etc.). We have long running threads
> which just do SELECTs and others that do transactions, some which can do
> either of these depending on external events. We've tried to make the
> SELECT only connections 'autocommit' so they don't start transaction blocks,
> and we've tried to enforce .Commit() on other situations, but the code is
> complex enough that sometimes the wires get crossed, and a Commit() s done
> on an autocommit connection. All of this is to prevent gigenormous
> data bloating from week-long <IDLE> in transactions.
>
> in the JDBC releases for PG 8.x, this was quietly ignored. On the new 9.x
> JDBC releases, this crashes with an ugly exception.
>
> My very-oracle-centric lead SQL developer is trying to use this as yet
> another excuse not to use Postgres as in his opinion, Oracle just 'does what
> you want'. ok, it does what HE wants, meh.
>
> Meanwhile, these random crashes that only show up under full production
> volume workloads (at our deployment sites in Asia) are freaking out the
> operations people, who ALSO are becoming afraid of Postgres.
>
>
>
> --
> john r pierce N 37, W 122
> santa cruz ca mid-left coast
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc