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: No, since if we were to do this properly, you'd have to get clients to participate in 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 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. - 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 - 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. Thoughts? -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache