Does Hibernate/Spring write immediately to database if no @Transactional is used?

Question

I summarize the case below, but what I am facing seems to be a "lost update" issue even though I am using locks that do not allow more than one thread at a time to be able to write to the DB.

Locks, i.e., reentrant locks, synchronized, semaphores, etc, all work well in preventing more than one thread to gain access to the shared area.. no issue here. The following is the setup in a nutshell:

I get two Java threads as a result of two users clicking on a button to increase a counter. Each user issues repeated updates to the counter, which is a field in a Mysql table. Basically, If users click on the button slowly, there is no lost update. When they speed up the clicking on the UI of each user, I see the missed updates.

In order to prevent the two threads from stepping on each other's foot, each thread needs to get a lock to the shared code area. I would not use java locks if I had multiple servers. The whole application is on a single server.

What I am seeing is that even though a thread writes to the database and releases the lock, the next thread sees some older value for the field. I removed all @Transactional statements to rule out any Spring tranactions issues, but the lost update is still there.

So, if the repository (DAO) writes to Mysql, doesn't that guarantee that the value is committed and persisted? Remember, no @Transactional statements are used here. I also tried flush after save in the repository module.

Any ideas? What am I missing?

Answer 1

@Transactional annotation is always used for data modifying methods. It is used not only for a transaction itself, but to open and close a persistent context (Hibernate session) too!

For example you can check an implementation of JpaRepository save() method

    @Transactional
    @Override
    public <S extends T> S save(S entity) {

        if (entityInformation.isNew(entity)) {
            em.persist(entity);
            return entity;
        } else {
            return em.merge(entity);
        }
    }

An idea to use java locks is not very good. Why you have such behavior? I think it is not a transactional issue, probably you have implemented multithreading code incorrectly.

The best way is to use JPQL update to update a counter

update ButtonEntity set couner = counter + 1 where id = :buttonId

Another option is to use a pessimistic lock.