如何避免Informix中的锁定异常

Question

I have one table of uuid which contains four columns: id, uuid, used(true/false) and version for optimistic locking. There are about 10000 records. When I want to insert new person to table person I read first not used uuid from table. Then I update this records that is already used and insert new person. But when I run performance test I have problem with table uuid and with selecting or updating records. There are lot of timeout lock ISAM error:

Caused by: java.sql.SQLException: ISAM error: Lock Timeout Expired
    at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:413) ~[ifxjdbc.jar:?]
    at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3982) ~[ifxjdbc.jar:?]
    at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2698) ~[ifxjdbc.jar:?]
    at com.informix.jdbcx.IfxXASqli.receiveMessage(IfxXASqli.java:116) ~[ifxjdbcx.jar:?]
    at com.informix.jdbc.IfxSqli.executeCommand(IfxSqli.java:939) ~[ifxjdbc.jar:?]
    at com.informix.jdbc.IfxResultSet.b(IfxResultSet.java:304) ~[ifxjdbc.jar:?]
    at com.informix.jdbc.IfxStatement.c(IfxStatement.java:1283) ~[ifxjdbc.jar:?]
    at com.informix.jdbc.IfxPreparedStatement.executeUpdate(IfxPreparedStatement.java:421) ~[ifxjdbc.jar:?]
    at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate(WSJdbcPreparedStatement.java:1187) ~[com.ibm.ws.runtime.jar:?]
    at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:804) ~[com.ibm.ws.runtime.jar:?]

How can I avoid this exception ? Isolation level in webshere is set to TRANSACTION_READ_COMMITTED lock mode wait is set to 2s and table has row lock

Answer 1

2 seconds timeout is very very short. How many concurrent threads are you using for the testing? I'll bet you barely have time to commit before 2s expires. Use 30s, and modify your code to get the next value from the uuid table and commit as quickly as possible! Do not perform other work. I'd recommend allocating a new uuid, insert the new user row and commit. Then proceed with other work.

Also, adding users does not strike me as something that needs heavy performance testing for concurrent activity. However if you're going to use this technique on another table that WILL be heavily accessed, you may have a real problem.