[hibernate-dev] Hiberante OGM Infinispan Remote dialect - Execute the command queue as a single Infispan Remote Server Task

Tue Feb 6 09:17:58 EST 2018

On 02/06/2018 02:55 PM, Sanne Grinovero wrote:
> Thanks for starting this, great ideas.
>
> We should start exploring such options but I am thinking of some more
> limitations that we'll have to overcome. To keep the discussion from
> getting hopelessly complex, let's try to clarify the purpose:
>
> The goal is to solve two problems which are strongly related:
>    # performance / efficiency
>    # better ACIDity of "transactions"
>
> # Efficiency
> Radim makes a great point, it would be nice to be able to address the
> optimal node for any "task" we might want to perform.
> JIRA:
>   - https://issues.jboss.org/browse/ISPN-8770
>
> However while we wait for the Infinispan team to provide such
> refinements, I think we should go ahead with this plan already, not
> least for the other reasons, but also to be able to eventually provide
> quick feedback on such improvements.
>
> Clearly this means we'll incur (possibly?) a performance hit when
> running a simple task - such as writing a single key - but it
> shouldn't matter much for more complex operations: especially with a
> small sized cluster chances are high to hit a node owning at least one
> of these.
>
> For the moment our client could detect if it's preferrable to run a
> task or a "simple op"; essentially we could implement some of
> ISPN-8770 in our Dialect but rather than making this too complex on
> our side I'd contribute to the Infinispan improvement first.
>
> # "one transaction, one task" ?
>
> Just to clarify, we can't promise that the ORM won't need to flush
> multiple times before the transaction is finally committed. Make sure
> you read about auto-flush strategies, either in our docs or there are
> many good articles about the topic.
> In a nutshell, if there are dirty entities of some type A, and then a
> query is run on that same type A, the ORM engine needs to flush the
> pending changes on all As first to make sure the queries are accurate.
> We could debate if this is appropriate and maybe we shouldn't do it on
> all NoSQL stores, but it's certainly debatable as it's a change in
> semantics compared to what people are used to.
>
> It's not entirely bad news though; while a single transaction might
> actually be performed by multiple, independent although ordered "Task
> RPC"s this will give us some opportunity to at least make sure that
> operations which really need to be atomic will happen atomically; for
> example when we delete an entity we can make sure that all references
> are cleared up correctly. However it's not a real transaction still
> and we need to be clear about that, no big deal as "real transactions"
> will come soon in Infinispan Remote too.

About 'real transactions': beware that current design for the Hot Rod 
transactions does not involve executing scripts withing the scope of the 
ongoing transaction. Since the server-side is already in master (for a 
while now), the protocol that lacks support for script execution in 
transaction is set. It was a 'start small' decision, so if this appears 
to be critical for your use cases please shout aloud on infinispan-dev 
list to influence that.

>
> # Usability
>
> Just a note on this. I hope we can try to work on this while expecting
> that the Infinispan Server won't need to have specific code deployed
> which depends on the specific application, such as the object model.
> If it helps we can think of an "OGM extensions" to be included with
> the Infinispan Server, but the code we include would then need to be
> able to work with any schema. Ideally, even with multiple versions of
> OGM, so I'd hope that we can design the models of each task we'll need
> as Protobuf Entities.

I hope you won't end up with OGM generating javascript to be run on the 
server :)

Radim

>
> Fabio, do you want to start working on such a POC?
>
> Thanks,
> Sanne
>
>
>
>
>
> On 5 February 2018 at 15:05, Fabio Massimo Ercoli <fercoli at redhat.com> wrote:
>> Hi Radim,
>>
>> thank you for the alternative, it is very interesting.
>> I've to study deeply the feature :P
>>
>> Fabio
>>
>>
>> On Mon, Feb 5, 2018 at 9:53 AM, Radim Vansa <rvansa at redhat.com> wrote:
>>
>>> 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 at redhat.com>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>> --
>>
>> FABIO MASSIMO ERCOLI
>>
>> Senior Software Engineer - Hibernate & Data Platform
>>
>> Red Hat <https://www.redhat.com/>
>>
>> fabio.ercoli at redhat.com    M: (+39)-329.8681441
>> <http://redhatemailsignature-marketing.itos.redhat.com/>
>> <https://red.ht/sig>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team