Infinispan cache.computeIfAbsent runs in a separate thread on new WF

[Ehsan Zaery Moghaddam]

Hi

I'm migrating from WF 18 to 24. In the code we're using cache.putIfAbsent in many places and pass it a function that loads some data from db to put in the cache. Seems in the new version, the provided function/lambda is being executed in a separate thread so it doesn't have the same transaction as the caller. I confirmed this by checking the thread name in both old WF and the new one.

Here is a sample code:

@Resource(name = "sample-cache")
private Cache<String, Boolean> sampleCache;

public boolean getFromCache(String key) {
    logger.info("log from the caller method that the cache is injected into");
    return sampleCache.computeIfAbsent(key, k -> {
        logger.info("log from lambda expression passed to the cache.putIfAbsent");
        // load data from db via entity manager
        // return loaded data;
    });
}

And the output is as below (thread name is shown in bold)

2021-11-12 09:30:40,848 [default task-1] log from the caller method that the cache is injected into

2021-11-12 09:30:41,683 [non-blocking-thread--p25-t20] log from lambda expression passed to the cache.putIfAbsent

The actual exception I get is from Hibernate complaining that there is no session to fetch the lazy property. It's obviously because the code is now being run inside a thread with no transaction.

WF 18 is using Infinispan 9.4.16

WF 24 is using infinispan 12.1.4

I couldn't find in any documentation/forum about whether this is a change in Infinispan behavior or if it's something that can be configured in server/application level. I need to make sure the code is running in the same thread as caller (as it is in WF 18).

Any help would be appreciated.

Regards

Ehsan

[Ehsan Zaery Moghaddam]

For future references:

I talked with the Infinispan community and the final conclusion was that it was just a coincidence that the lambda expressions were being executed in the same thread as the caller method. It was most probably due to the fact that they were using blocking io API in their cache persistence process and now that it's changed to a non-blocking API, the code got affected.

The suggestion solution was to first check if data exists in the cache and if not load it in the caller code and use putForExternalRead method to put it in the cache.