CODEWITHSUNDEEP
javaspringcassandra
henry
henry

Reputation: 129

Spring Cassandra Repository - Saving a record in a background thread

I've been working on creating a record in my database on a background thread but I don't get any response in the console (No errors, exceptions or logs).

Below is the code

In my spring component I have:

ExecutorService tPool = Executors.newFixedThreadPool(15);

//This is a repository that extends CassandraRepository
@Autowired
MyRepository myRepository;

CompletableFuture<Boolean> myBool = CompletableFuture.supplyAsync(() -> {

            //processing here

            return new doSomeProcessing(arg1, arg2, arg3).process();
        }, tPool);

myBool.whenComplete((isTrue, throwThis) -> {
   if(isTrue) {
      // do something
   }
});

In my Class doSomeProcessing, I have the method process():

public boolean process() {

//This appears in the console
LOG.info("About to try and save the record on the background thread");

//After setting the repository in the thread class constructor
myRepository.save(arg1, arg2, arg3);

//This doesn't appear in the console
LOG.info("The record should be saved");

}

But the database doesn't show any new records and the console doesn't show any errors or exceptions or the last log statement.

How would you go about saving a record on a background thread using Spring with Cassandra?

Any explanation is greatly appreciated.

I've seen and tried the below with the async service and transactional as well as a few others: How do I use JpaRepository in a backend thread?

How do I properly do a background thread when using Spring Data and Hibernate?

Upvotes: 0

Views: 569

Answers (1)

Kayaman
Kayaman

Reputation: 73568

When a CompletableFuture is completed exceptionally, there's no stacktrace because the exception is still unhandled. It's stored until the user does something that "activates" that exception. For example calling get() would directly throw that exception.

When doing more complex things with CompletableFuture the exception is stored along the results of the future (hence BiConsumer to have result and exception as parameters), but it's up to you to check if there is an exception and handle it.

Since you can chain the futures and therefore encounter multiple exceptions, you end up with documentation like the following:

If the supplied action itself encounters an exception, then the returned stage exceptionally completes with this exception unless this stage also completed exceptionally.

If you understand that on the first read, you're talented.

Upvotes: 1

Related Questions