Hi @Tegar_ASK ,
This might be a case of one adapter connection trying to auto-commit a record on a record or page while another connection is trying to read data from the same block.
You might have to think of the folloing approach
Keep your existing services which perform insert’s, updates, deletes using the same adapter connection.
-Create a new adapter connection to the same database only for read purposes with the settings of transaction isolation (provided it suits your requirements) such as being able to ready uncommitted data.
This is just a though -btw changing the reading adapter service which does the read is not as hard as it seems you could refer to pub.art.service:setAdapterServiceNodeConnection which can do this task without your team having to rebuild the code.
There is a timeout on the adapter service itself. The adapter connection settings you list are for the connection session, not the execution of a statement. The fun part is when it is created it defaults to -1 which means “wait forever.” Should never do that on any adapter calls (DB or other) nor on any HTTP calls.
Not sure if that is the case here but is something to check.
Block timeout is the amount of time a thread will wait for a pool connection before giving up and throwing an error. This has nothing to do when an individual adapter service waits for a response. This applies only to threads waiting to get a connection from the pool.
Expire timeout is the amount of time a connection in the pool is allowed to remain idle. If not used within the expire timeout, the connection will be closed (should be set to just short of what the DB idle connection timeout is).