Update SQLS will lead dead lock exception. Because by default, it use optimistic lock but not pessimistic lock.
Below description is exceprted from the attachment(It exceeds my image that this blog can not upload the attachment,hehe)
Optimistic locking offers an elegant solution to the problems outlined above. Optimistic locking does
not lock records when they are read, and proceeds on the assumption that the data being updated has not
changed since the read. Since no locks are taken out during the read, it doesn’t matter if the user goes to
lunch after starting a transaction, and deadlocks are all but eliminated since users should never have to
wait on each other’s locks
There are some ways to resolve this problem.
1. Create a pessimistic lock. Change the sql like below formal.
First: select … from … for update nowait
Second: update the resultSet.
2. Execute the SQL again after a random duration when program meets this kind of exception. (It will consume lot of db server resource. I don't think it is the better way)
3. Schedule the SQL executed sequenced or split data without interfere.