Question

I want some advice on some concurrency issues regarding jdbc, i basically need to update a value and then retrieve that value using a update then a select, I’m assuming by turning auto commit off no other transaction can access this table, hence other transactions won’t be able to perform update and select queries until this has been committed.

Below is some example code. Do you think this will work and does any one else have a better solution to implementing this?

int newVal=-1;
con.setAutoCommit(false);
PreparedStatement statement = con.prepareStatement("UPDATE atable SET val=val+1 WHERE id=?");
statement.setInt(1, id);
int result = statement.executeUpdate();
if (result != 1) {
    throw new SQLException("Nothing updated");
} else {
    statement = con.prepareStatement("SELECT val FROM atable WHERE id=?");
    statement.setInt(1, id);
    ResultSet resultSet = statement.executeQuery();
    if (resultSet.next()) {
        newVal =  resultSet.getInt("val");
    }
}
statement.close();
con.commit();
con.setAutoCommit(true);

Thanks.

Answer 1

Assuming you use some form of data source, you may configure there if you want transactionality and the isolation level. But to be explicit:

try(Connection con = ds.getConnection()){
   con.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
   con.setAutoCommit(false);
   //...
} catch(SQLException sqle) {
   throw new MyModelException(e)
}

Now, you could trigger pesimistic locking by updating a version (or timestamp) field in your table. This will trigger a lock in the database (most likely at the record level):

try(PreparedStatement pStm = con.prepareStatement("update atable set version=version+1")){
   pStm.executeUpdate();
}

At this point, if another user is trying to update the same record simultaneously, this connection will either wait or timeout, so you must be ready for both things. The record will not be unlocked until your transaction ends (commit or rollback).

Then, you can safely select and update whatever you want and be sure that nobody else is touching your record as you process your data. If anybody else tries they will be put on wait until you finish (or they will timeout depending on connection configuration).

Alternatively you could use optimistic locking. In this case you read your record, do modifications to it, but in the update you make sure nobody else has changed it since you read it by checking that the version/timestamp field is the same as the one you orginally read. In this case you must be prepared to retry a transaction (or abort it alltogether) if you realize you have stale/outdated data.

i.e. update atable set afield=? where id=? and version=1

If the number of rows affected is 0, then you know that is probable that the record was updated between your read and your update and the record is no longer in version 1.