Re: commit problem
От | Dave Cramer |
---|---|
Тема | Re: commit problem |
Дата | |
Msg-id | CADK3HHJiERt634=je1HQR7YcHj4YV6WZ07fgaoP0Oim2JWuPFQ@mail.gmail.com обсуждение исходный текст |
Ответ на | commit problem (John R Pierce <pierce@hogranch.com>) |
Список | pgsql-jdbc |
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@hogranch.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
В списке pgsql-jdbc по дате отправления: