IDS Forum

Tracking down a transaction isolation issue

Posted By: Laird Nelson
Date: Wednesday, 7 November 2012, at 10:17 p.m.

I am trying to fully understand a scenario in Informix that has been
bedeviling me for a long time.

To be clear I am sure the error is mine but I want to understand why I am
seeing the behavior I'm seeing.

In the following scenario I am using an isolation level of "5" (READ LAST
COMMITTED, the JDBC driver guide tells me). I've verified this on the
database that indeed the connections attached to this database are at this
isolation level.

The database is set up with unbuffered logging, so transactions are enabled.

I am interacting with Informix via an Enterprise Java Bean and JPA, so when
I start talking about transactions they are started for me by the EJB
container in conjunction with the Informix JDBC driver by way of JPA.
Standard (Java) stuff.

My scenario is this:

I start a transaction. In this transaction I select a bunch of records
from a table set up with row locking. These records come from "type"
tables--tables referred to by foreign keys in a master table somewhere else.

Then for various reasons some of which are valid and some of which are
highly suspect :-) in a new transaction I go about updating the master
table. The old transaction is at this point (again, for good and bad
reasons) still in effect.

Kaboom (-107; record locked).

Despite the fact that these two transactions are isolated from one another
(isn't that what it means to be transactional? Isn't that the "I" in
ACID?), the second one fails because a detail record in the first one is
locked, even though my isolation level should let me read committed values
from the detail table when a lock is encountered.

Specifically, the second one fails because when I attempt to insert the
master row, during the foreign key referential integrity check to see if
I've tied my new master record to an appropriate detail record, Informix
cannot find a suitable target (a suitable detail row), because in order to
do so it would need to read the detail row, and the first transaction has
that row locked.

My Java stack trace shows me that at the bottom is a -107 error (row
locked), and that causes a referential constraint violation, and that
causes my app to fail.

This is very surprising to me.

In PostgreSQL, which I've run this code on, these two transactions are
isolated from one another: the fact that the first one is still in effect
does not block the second from reading the detail row. The isolation in
this case is READ_COMMITTED (ANSI), which is equivalent (I'm told) to
Informix's READ LAST COMMITTED. This is true on SQL Server as well (and
H2).

It seems to me, then, that as long as the first transaction has selected
some row in a table somewhere that the second transaction has to read, I am
hosed unless I drop the isolation level down to something even "dirtier"
(but then JPA, my technology that I'm using to read and write from the data
tier, is guaranteed not to work (it requires at least a READ_COMMITTED
(ANSI) isolation level)).

What is the general pattern for a scenario like this? Or please, if I'm
being abysmally stupid please do let me know how and why.

Thanks as always,
Laird

--
http://about.me/lairdnelson

--20cf3074b69241075104cdf345d8

Messages In This Thread

• Tracking down a transaction isolation issue
  Laird Nelson -- Wednesday, 7 November 2012, at 10:17 p.m.
  • Re: Tracking down a transaction isolation issue
    Laird Nelson -- Thursday, 8 November 2012, at 12:10 a.m.
    • Re: Tracking down a transaction isolation issue
      Fernando Nunes -- Thursday, 8 November 2012, at 5:28 a.m.
    • Re: Tracking down a transaction isolation issue
      BRYCE STENBERG -- Thursday, 8 November 2012, at 3:38 p.m.
      • Re: Tracking down a transaction isolation issue
        Laird Nelson -- Thursday, 8 November 2012, at 6:29 p.m.
  • Re: Tracking down a transaction isolation issue
    Fernando Nunes -- Thursday, 8 November 2012, at 5:24 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.