RE: Row Level Locking via JDBC
you will get the error message if the query does a sequential scan on the
table, do the following from dbaccess to verify this
1)run the following statement from "Query-Language"
set explain on;
select * from where id = 1;
2) check the sqexplain.out file and see if the optimizer does a sequential
scan on the table
you can avoid this error by doing the following,
1) creating an index on id, like
create index idx1 on dummy(id);
2) if the dummy table is small, use the INDEX optimizer directives to force
the optimizer to pick the index, like
update {+ index(dummy idx1) } dummy set counter = 3 where id = 1
-----Original Message-----
From: owner-informix-list@iiug.org
[mailto:owner-informix-list@iiug.org]On Behalf Of soeren.ehm@evodion.de
Sent: Wednesday, May 19, 2004 2:25 AM
To: informix-list@iiug.org
Subject: Re: Row Level Locking via JDBC
More precisely, I set row level locking in the table dummy.
CREATE TABLE Dummy (
ID integer NOT NULL,
Counter integer
) LOCK MODE ROW;
The focus is laying on the following update statements. Why I can't
update different rows in the same table by two connections which
simulating two clients.
conn1.setAutoCommit(false);
conn2.setAutoCommit(false);
st = conn1.createStatement();
st.executeUpdate("update dummy set counter = 3 where id = 1");
st = conn2.createStatement();
st.executeUpdate("update dummy set counter = 3 where id = 2");
conn1.commit();
conn2.commit();
I don't understand, why I get the error message
- "Could not do a physical-order read to fetch next row.".
Normally, this could't be right with row level locking.
Soeren
sending to informix-list