[infinispan-dev] Hot Rod: To be or not to be transactional and flags

[Galder Zamarreno]

See below:

On Thu, 11 Mar 2010 20:17:53 +0100, Mircea Markus  
<mircea.markus at jboss.com> wrote:

>
> On 9 Mar 2010, at 18:38, Galder Zamarreno wrote:
>
>> Hi,
>>
>> While writing some tests for the Hot Rod server, the following came to  
>> my
>> mind: Are we gonna enable clients to being/commit/rollback transactions
>> remotely? The simple answer is:
> <snip>
>> No, since if we were to do this properly,
>> you'd have to get clients to participate in the transaction
> </snip>
> what do you mean by making clients participate in transactions? JTA  
> compliant clients, that would determine the tx associated with the  
> calling thread etc?

I mean remote clients of Hot Rod servers being able to  
begin/commit/rollback transactions and in the middle send hot rod servers.  
If you're to do this properly, clients would need to be some kind of XA  
resource or similar, so that both Hot Rod servers and clients participate  
of the transaction.

>> and this is
>> quite a complex thing to do based on my experience wrt EJB user
>> transactions started from remote clients.
>>
>> In this case, the following flags do not make sense in the Hot Rod case:
>> FORCE_WRITE_LOCK -> there's no transaction, so a read acquiring a WL  
>> would
>> be useless
>>
>> The following are bit dubious but still potentially useful because the
>> lock acquisitions would be per call, so locks would be acquired for a
>> pretty short period of time:
>> ZERO_LOCK_ACQUISITION_TIMEOUT
>> SKIP_LOCKING
> good point
>>
>> I think the rest of flags do make sense but might require some renaming:
>> - CACHE_MODE_LOCAL- you could still want to store something in one node
>> only even if the hot rod servers are replicated/distributed.
> not sure, as there's no way for a client to specify to which server to  
> connect. Not sure I see a use case for this.

Hmmm, the client does connect to a server, so it knows the server to which  
is sending data even if the message does not contain server information.  
So, if you have HR servers A, B and C which are configured with repl/dist,  
and client connects to server B, would he want to store something only in  
B? I think this might still be useful.

>> - SKIP_CACHE_STATUS_CHECK - as it is.
>> - FORCE_SYNCHRONOUS - this could make sense. clients, as well as waiting
>> for response, want to know that it was replicated/distributed correctly  
>> in
>> asynch configured hot rod servers.
>> - SKIP_CACHE_STORE - as it is, clients might to avoid writing to the  
>> cache
>> store.
>> - SKIP_REMOTE_LOOKUP - as it is but would need renaming
> - again, as there's no way to know to which server you are connected not  
> sure I see a use case for this

Hmmm, see above. Maybe the client API is shielding which server messages  
are sent to?

>> - PUT_FOR_EXTERNAL_READ - as it is.
>> - FAIL_SILENTLY - as it is.
>>
>> Finally, some might not make sense:
>> - FORCE_ASYNCHRONOUS - this does not make sense, clients can simply not
>> wait for response and that would be asynchronous for them
> +1
>>
>> Thoughts?
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache