Batuhan Balı question on Medium www.linkedin.com/in/batuhanb19/ Hi, I read the entire article even though I do not work with Spring Boot or Java, what can I say It could not have been explained in a better way. But there is something that i want to know. - In optimistic locking if the version does not match it will throw an exception. After the exception what would you prefer to do with that ? For instance would you try to start the other transaction after it failed. Answer: Hi there, that's a really good question. However, it really depends on business requirements. For example, consider a scenario where there is only one stock of a product, and you've sold it. Another transaction comes into play and attempts to buy it. However, there is no product in stock anymore. When you retry, it will throw an exception, or some other issues might appear. That's why throwing an exception and notifying the client would be useful in that case. On the other hand, let's say you have a user, and you want to update their name. In this case, when a transaction encounters an error, a retry mechanism is entirely useful. Business analysis will guide us in determining the appropriate approach.
En sonda biz buna karar vermiyoruz dedim. Aslında retry veya hata fırlatma senaryosuna elbet de karar veriyoruz. Bu genellikle analize göre şekillenen bir durumdur. Örnek aynı anda ürünler satın alınmak istendi fakat yeterli ürün miktarı kalmadı burada Retry yapmak çok mantıklı bir seçenek olmayacaktır. Örneğin kullanıcı adını değiştirmek istedi ve o anda bir pencereden yada client'dan bunu yapınca bir conflict oldu burada retry yapmak son derece mantıklıdır. Bu analize göre şekillenen bir durumdur.
medium.com/@beratyesbek/pessimistic-and-optimistic-locking-in-jpa-spring-boot-aa59f2b906fa www.linkedin.com/in/emre-binnaz-6b482017b/ Emre Binnaz's Question on Medium Hello, I read the article. It was very explanatory and useful for me. I have a question. I am confused one point at PESSIMISTIC_WRITE. You mentioned about no other transaction is allowed to perform read or write concurrently in PESSIMISTIC_WRITE. I got it. However , it seems PESSIMISTIC_WRITE allows to read operation concurrently according to following line : "This allows other transactions to acquire shared locks on the same rows for reading..." How is it possible ? Thanks your answer. Answer Hi there, Thanks for this great question. In the context of JPA and Hibernate, the PESSIMISTIC_WRITE lock mode is indeed a pessimistic lock and is usually intended to prevent other processes from both reading and writing simultaneously. I got it confused because FOR NO KEY UPDATE is a PSQL clause. PESSIMISTIC_WRITE (JPA): Primarily used in JPA to acquire a pessimistic write lock on an entity during a SELECT operation. Prevents other transactions from acquiring any lock (read or write) on the same entity until the lock is released. It is designed to ensure data integrity by allowing only one transaction at a time to read or write to the entity. Shared Locks (FOR NO KEY UPDATE in PostgreSQL): In the PostgreSQL-specific FOR NO KEY UPDATE clause, it is possible to acquire shared locks for reading on the selected rows, allowing concurrent reads from other transactions without preventing them from acquiring exclusive locks for update or delete operations. I used PSQL in this project. It is a specific thing in PSQL. Some database systems implement multi-version concurrency control that allows readers to fetch data that has been already blocked. [quoted] www.baeldung.com/jpa-pessimistic-locking Other sources: stackoverflow.com/questions/59712313/what-is-the-practical-use-of-for-key-share-in-postgres www.postgresdba.com/bbs/board.php?bo_table=C05&wr_id=186 www.migops.com/blog/select-for-update-and-its-behavior-with-foreign-keys-in-postgresql/
