+1. This is workaround only works with java clients, which way too restrictive for Hotrod, so we cannot consider this as a solution even if we'd want to :-)Mircea,
I applaud the effort and your experiment! Having said that I think we have to engineer a much more plumbing for more complicated cases, e.g map/reduce (marshalling results, classloading etc etc). I am more and more convinced nowadays that all of this plumbing is better provided by AS itself rather than us reinventing the wheel here...
WDYT?
Vladimir
On 11-07-15 7:53 AM, Mircea Markus wrote:Hi,
As there is a high community demand for having these operations in place, and most of these are targeted for post 5.1 releases, I thought about a workaround for having this functionality in place.I hijacked Hotrod's put operation and added a custom interceptor, so that if a certain object is being "put" into remote cache, the server side interceptor jumps in and runs transactions.This doesn't look too bad for the user, e.g. for supporting transactions:
RemoteCache rc = getRemoteCache();//from somewhere... //this is what we'll use for running remote transactions over hotrod BatchEnabledRemoteCache berc = new BatchEnabledRemoteCache(rc); berc.startBatch(); //everything from here to endBatch call is a single transaction berc.put("k", "v1"); berc.put("k2", "v2"); berc.put("k3", "v3"); berc.endBatch(true); // all or nothing!
Of course this won't work with other clients than the java client, but I think most of our users are using that one ATM.Currently there's only support for transactions but this approach (and the code) can be easily extended to mapreduce and querying.I added s short description on how this can be used [1], also the source code is available here[2].
What do you think about it? Is it worth suggesting to the users this approach(and possibly the code as well)?
Cheers,Mircea
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev