Hi Fabio,
thinking about the cons, Hot Rod can intelligently pick the server where
should a given key reside, to reduce the number of hops (therefore,
latency). RemoteCache does not expose any way to route according to some
key; feel free to file a feature request in Infinispan JIRA.
Note that in order to reduce the number of round-trips, Infinispan 9.2
will support true-async operations: Previously the putAsync et all just
moved the execution to different thread, since 9.2.0.CR2 it sends the
request to the wire right await and the response is received through a
CompletableFuture. At this moment multiple requests will need a distinct
TCP connection for each concurrent operation, but this limitation is
likely to be removed in 9.3. The goal is to let you write the batch down
one-by-one using async API and just wait for all the operations to complete.
I know this won't help for all the types of operation (a lack of
client-side API sometimes forces OGM to use get() + CAS in a loop).
I am not trying to talk you out of the remote execution API, just
spreading news about the emerging alternatives.
Radim
On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote:
I'm Fabio, nice to meet you.
Speaking of the current implementation of the Infinispan remote dialect of
Hibernate OGM, working on issue OGM-1206 and talking with Davide I noticed
that the unit of work commands are executed (flushed to datastore) at the
end of the transaction itself.
In particular I noticed that the commands are stored in a transaction
scoped object of type org.hibernate.ogm.dialect.batch.spi.OperationsQueue.
Instead of perfom one remote invocation for each command in the method
org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
maybe we could invoke a proper Infispan Remote Server Task to execute the
command queue on server side as a bulk operation.
Moving the execution of the server-side command list (Infinispan) we would
have the advantage of reducing remote interactions. Moreover and above all
the execution of the command queue would be a transactional work unit, on
which could be apply a Repeteable Read isolation level, for instance.
The solution would not solve the need for an XA client instead, but it
could be adopted by customers interested in local transactions.
What do you think about it?
Can I open a Jira issue?
Fabio
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team