Skip site navigation (1) Skip section navigation (2)

Re: Connection.setReadOnly()

From: John R Pierce <pierce(at)hogranch(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Connection.setReadOnly()
Date: 2009-12-11 00:57:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Oliver Jowett wrote:
> Because if they're operating on a connection with autocommit off, the
> JDBC spec is very specific about transaction boundaries, and it would
> actually be incorrect for the driver *not* to start a transaction. I
> have at least one application here that runs readonly queries inside a
> transaction specifically because it wants a consistent view.
> Does the Oracle driver not follow the JDBC spec here? Or is it just that
> long-term open transactions don't cause problems on Oracle?

the latter.   long term transactions are not a problem for Oracle.   As 
I said, they've been using an open transaction with a row lock as a 
MUTEX for an app that runs for weeks or even months.

> If your oracle developers don't want manually committed transactions,
> perhaps they should.. turn on autocommit.

otherwise, an app thats doing purely read queries has to periodically 
issue a Commit().   I have to say, doing Commit() on read operations is 
NOT at all intuitive.

> It's somewhat telling that they identify themselves as "Oracle people".
> Postgres isn't identical to Oracle; if you want applications that are
> portable between RDBMSes you need to take some care, and presumably they
> didn't do this originally and are now paying the price.

These two SQL developers have been working on this same family of 
manufacturing databases in oracle for like 12-15 years.   Its me thats 
calling them 'oracle people' :)

In response to


pgsql-jdbc by date

Next:From: Oliver JowettDate: 2009-12-11 01:16:38
Subject: Re: Connection.setReadOnly()
Previous:From: Oliver JowettDate: 2009-12-11 00:46:20
Subject: Re: Connection.setReadOnly()

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group