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 <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev