Re: revisiting transaction isolation

On Sat, 17 Jul 2004, Oliver Jowett wrote:

> Currently, this type of code will fail:
>
> > conn.setAutoCommit(false);
> > if (conn.getTransactionIsolation() != Connection.TRANSACTION_SERIALIZABLE)
> > conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
>
> The problem is that getTransactionIsolation() issues a query and thus
> starts a new transaction, and then setTransactionIsolation() complains
> you can't change isolation level mid-transaction.
>
> I'm not sure this is reasonable behaviour. One option is to make
> getTransactionIsolation (and what other methods too?) not cause a BEGIN
> to occur if there is no transaction in progress and autocommit is off.

I see no reason for getTransactionIsolation or any driver call to start a
transaction, these are only SELECTs and won't be rolled back anyway.

> On a related topic I just took a look at the JDBC3 spec and it says:
>
> > The return value of the method getTransactionIsolation should reflect
> > the change in isolation level when it actually occurs. It is recommended
> > that drivers implement the setTransactionIsolation method to change the
> > isolation level starting with the next transaction. Committing the
> > current transaction to make the effect immediate is also a valid
> > implementation.

This seems confusing and error prone. I would expect a command I issue to
take effect immediately or throw an Exception, not do nothing now, but
alter later behavior.

Kris Jurka