[infinispan-dev] Hot Rod: To be or not to be transactional and flags
Mircea Markus
mircea.markus at jboss.com
Thu Mar 11 14:17:53 EST 2010
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
More information about the infinispan-dev
mailing list