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

[Mircea Markus]

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?
> 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.
> - 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
> - 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