If you have one thread, that has sequential join() calls, then each call to join() would block the thread, so that they will occur one after the other, i.e., synchronously.
If you have multiple threads, each one calling one join(), then all the join() calls should be concurrent because the threads are concurrent.
And as you say, you have concurrent transactions, that means the calls to doRequest() are concurrent => join() is concurrent.
Well, thank you for your reply. Another problem is that I found that the ForkJoinPool thread pool is used by default to execute the requested task, but under high concurrency, the execution of each task becomes the LIFO mode, which will cause the first request to be processed longer and the transaction will start. The one with the larger timestamp will be executed first. Does this have any effect? Why use this thread pool?
public DgraphAsyncClient(DgraphGrpc.DgraphStub... stubs) {
this.stubs = asList(stubs);
this.executor = ForkJoinPool.commonPool();
this.jwtLock = new ReentrantReadWriteLock();
}
Define a DgraphStub through the serviceName of K8s, is it concurrent or serial to establish connection and communication for multiple threads in the thread pool? Is there a recommended client configuration for high concurrency scenarios?Now the default client is like this.
There is one more question. I would like to trouble you to answer it again. If a request contains query, set mutation, and delete mutation at the same time, if forkjoinpool is used, will these operations be processed in parallel by multiple threads? Such as between set mutation and deletion mutation.