Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>I thought that when DAO methods are covered with transaction, then only one thread will be inside it</p> </blockquote> <p>Based on your description, each call to incrementCounter should be running in its own transaction, but the threads are running concurrently so you would have two transactions running concurrently.</p> <blockquote> <p>(i.e., Spring will take care of synchronization).</p> </blockquote> <p>It sounds like you're confusing transactions with synchronization. Just because two threads are running their own transaction does not mean that the transactions will be serialized with respect to each other, unless your transaction isolation level is set to SERIALIZABLE.</p> <blockquote> <p>I also thought that entity manager would give me the same entity instance from the cache of the persistence context</p> </blockquote> <p>Yes, within the scope of the persistence context. If your persistence context has transaction scope, then you're only guaranteed to get the same entity instance within the same transaction, i.e. within one invocation of incrementCounter.</p> <blockquote> <p>Should DAO methods be synchronized?</p> </blockquote> <p>As mentioned in other posts, typically DAO methods are CRUD methods, and you don't usually synchronize since the DAO is simply selecting/updating/etc. and doesn't know the larger context of what you're doing.</p> <blockquote> <p>Is spring responsible for making the calls to DAO methods behave transactionally? (i.e. not letting two threads work with the same entity at the same time)</p> </blockquote> <p>Again, transaction != synchronization.</p> <blockquote> <p>If not, how do I achieve this?</p> </blockquote> <p>As mentioned in other posts, you can do synchronization at the Java level or set your transaction isolation level to SERIALIZABLE. Another option would be to use SELECT FOR UPDATE syntax (e.g. LockMode.UPGRADE in Hibernate) to inform the database that you intend to make a change and the database should lock the rows.</p> <p>If you're not tied to pessimistic locking, you can implement optimistic locking, e.g. using Hibernate versioning. You would get a lot of optimistic lock failures with your specific incrementCounter example, but one would assume a real application would not behave like that.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload