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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev