Skip to content
Advertisement

Tag: locking

Locking execution within CompletableFuture

I need to post-process result of CompletableFuture.supplyAsync execution to get intermediate result. My code looks following In a result I’m facing with java.util.concurrent.CompletionException: java.lang.IllegalMonitorStateException on .thenAccept(resultPerBatch -> { line Seems like I’m using lock in wrong way but I cannot figure out how to avoid this kind of exception. Answer There’s no guarantee that the Function passed to thenApply and

Try-finally with lock when no exception is thrown

In the java manual it says that it is recommended to use try-finally when using lock() and unlock(), but this is also necessary when an exception is never thrown in the try block? for example: Answer Adding it always is a reasonable advice: For a beginner, because they may not be aware of all the ways exceptions might be thrown.

How can I guarantee a thread is safely unlocking a lock upon termination, while all methods already handle it?

A server project, might run for very long time and create many threads. In the following code I ask myself do i have to protect the lock somehow in addition to an overall try catch in method setData(MyData data): note: assuming its thread-safe, i am not really familiar with other reasons or natural disasters that may cause thread termination, like

Execute query with MySQL GET_LOCK function in Hibernate

My application uses Hibernate as ORM. I am trying to execute few mysql locking function within my application like GET_LOCK, IS_FREE_LOCK, RELEASE_LOCK (https://dev.mysql.com/doc/refman/5.6/en/locking-functions.html). However I am running into following issue: Here is my Dao code: I am not sure how to execute locking functions using Hibernate. Any help/pointer is appreciated. Thanks in advance. Answer I found the problem. It was

Implementing a resource read/write lock in Java

I’m trying to implement a simple read/write lock for a resource accessed concurrently by multiple threads. The workers randomly try reading or writing to a shared object. When a read lock is set, workers should not be able to write until the lock is released. When a write lock is set, read and write are not permitted. Although my implementation

Mutex Locks vs Peterson’s Algorithm?

Do mutex locks ensure bounded waiting condition ? Is it possible if two threads are trying to get hold of a lock, but only one process (just by luck) gets it again and again. Since Peterson’s Algorithm ensures bounded waiting, is it better to use that instead of mutex locks ? Answer It is possible to have unbounded wait with

JPA PessimisticLockScope.NORMAL and locking “relationships”

I am studying JPA Documentation and encountered the following lines: Entity relationships for which the locked entity contains the foreign key will also be locked, but not the state of the referenced entities (unless those entities are explicitly locked). Element collections and relationships for which the entity does not contain the foreign key (such as relationships that are mapped to

Advertisement