Hibernate optimistic locking different behavior between Postgres and MariaDb

两盒软妹~` 提交于 2021-01-28 11:21:29

问题


I just discovered that my application behaves differently when I use optimistic locking with a Postgresql or a MariaDB database and I am wondering if somebody can explain what happens and how could I make the application work in the same way with MariaDB? I use Postgresl 10.5 and MariaDB 10.3.10 with InnoDB engine and default settings. I use Spring framework version 5.1.0 and Hibernate 5.3.6.

So my code looks like this:

@Entity
@Getter
@Setter
@NoArgsConstructor
public class Bla {

    @Id
    @GeneratedValue
    private long id;

    @Version
    private long version;

    private int counter;
}

I also have a repository for this entity and the following service method:

@Transactional
public int increment(long id) {
    Bla bla = blaRepo.getOne(id);
    bla.setCounter(bla.getCounter() + 1);
    return bla.getCounter();
}

If I call this method on multiple threads I would expect update would succeed only for a single one of them if they touch the entity with the same version. As an example: if I start 50 thread with Postgres db in one run I get 3 calls that succeed and return the values 1, 2, 3 and the other 47 fail with an ObjectOptimisticLockingFailureException which is the expected behavior - this is how I would like the app to behave.

However, if I switch to MariaDB then this doesn't happen. All 50 of these threads are completed successfully and I get the same response value in multiple threads as if there would be no optimistic lock. For example now the first 5 threads returned 1, then 20 of them returned 2, and the rest 3 or 4.

Why this is happening? It doesn't make any sense - with both databases the query generated is

update bla set counter=?, version=? where id=? and version=?

But in Postgresql will fail correctly and with MariaDB will succeed unexpectedly.


回答1:


The only way that could happen is of MariaDB had a bug because once a Tx modifies a record, it will lock it until it commits or rollbacks. Other Tx would block the UPDATE due to lock but the condition must be reevaluated after the lock is released.

Try to switch to READ_COMMITTED and see if it fixes the issue. It could be a REPEATABLE_READ anomaly.




回答2:


I found the solution to this problem.

It seems that I had this property set in application.properties:

spring.jpa.properties.hibernate.jdbc.batch_size = 50

When I do use Postgresql I get the following debug trace with two threads:

13223 [pool-2-thread-2] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=?
13223 [pool-2-thread-1] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=? 
13226 [pool-1-thread-1] DEBUG org.hibernate.engine.jdbc.batch.internal.BatchingBatch - Executing batch size: 1
13226 [pool-1-thread-2] DEBUG org.hibernate.engine.jdbc.batch.internal.BatchingBatch - Executing batch size: 1
13230 [pool-1-thread-1] ERROR org.hibernate.engine.jdbc.batch.internal.BatchingBatch - HHH000315: Exception executing batch [org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1], SQL: update bla set counter=?, version=? where id=? and version=?

and then with MariaDB with the same batch size 50:

21978 [pool-2-thread-2] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=?
21978 [pool-2-thread-1] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=? 
21979 [pool-2-thread-2] DEBUG org.hibernate.engine.jdbc.batch.internal.BatchingBatch - Executing batch size: 1
21979 [pool-2-thread-1] DEBUG org.hibernate.engine.jdbc.batch.internal.BatchingBatch - Executing batch size: 1
21980 [pool-2-thread-2] DEBUG org.hibernate.jdbc.Expectations - Success of batch update unknown: 0
21980 [pool-2-thread-1] DEBUG org.hibernate.jdbc.Expectations - Success of batch update unknown: 0

and then with MariaDB with batch size 1:

12994 [pool-2-thread-2] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=?
12994 [pool-2-thread-1] DEBUG org.hibernate.SQL - update bla set counter=?, version=? where id=? and version=?
12997 [pool-2-thread-1] DEBUG org.hibernate.cache.internal.TimestampsCacheEnabledImpl - Invalidating space [bla], timestamp: 6307671153053696
12998 [pool-2-thread-2] DEBUG org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl - JDBC transaction marked for rollback-only (exception provided for stack trace)

And now indeed the application throw the expected ObjectOptimisticLockingFailureException

But unfortunately this means that using MariaDb with optimistic locking on entities and any batch size greater than 1 is not compatible.



来源:https://stackoverflow.com/questions/52891978/hibernate-optimistic-locking-different-behavior-between-postgres-and-mariadb

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!