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

Re: Connection.setReadOnly()

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Connection.setReadOnly()
Date: 2009-12-11 00:41:28
Message-ID: 4B219538.2090203@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
John R Pierce wrote:
> Kris Jurka wrote:
>> Just because your connection is readonly doesn't mean that everyone
>> elses is as well.  If you want a consistent view of the database you
>> can get that with a serializable transaction.
> 
> my oracle developers are screaming bloody murder over this.
> 
> they have processes that do nothing but reads.   jdbc tosses a BEGIN;
> out automatically.   these processes never Commit(); on a read, why
> should they?

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?

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

> per all my Oracle people this is totally unacceptable and they are ready to cancel any further postgres projects. 

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.

-O

In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2009-12-11 00:46:20
Subject: Re: Connection.setReadOnly()
Previous:From: John R PierceDate: 2009-12-11 00:33:46
Subject: Re: Connection.setReadOnly()

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