Re: [infinispan-dev] transaction over hotrod

Hi, First of all, thanks Mircea for writing this up. These are my comments: I'm not sure I understand the meaning of or the point you're trying to make with: "Further on, it is possible (and not difficult) to build local transactions on top of global transaction: Infinispan's batching API does just that internally.". Transactionable clients doesn't sound very well to me. I'd go for 'transactional clients'. I don't think we should support this: "Through HotRod, operations associated with same transaction might be dispatched to multiple nodes. ". I think this is rather messy and will cause problems. Think of sticky sessions. Instead, I think transactional client implementations will need a new load balance policy which is transaction sticky. IOW, if you call begin tx on node A, you want the rest of transaction operations to be directed there. Otherwise, it gets very messy if the prepare lands on node B and commit on node C. So, wherever the beginTx lands, that's the node that should be used for the duration of the transaction. IOW, my vote is definitely for solution 1 which is simpler and avoids potential lock ups resulting from sending operations in the same tx to diff nodes. How are we gonna deal with situations where client sends a commitTx which is applied correctly in the target server and any other involved members in the cluster, but there's a failure when commitTx response is sent back to client? The client could think that the commit failed but this worked fine on the server. I think we need something other than client intelligence for determining whether a transaction is present or not for the following reason: Imagine that as part of transactional operation the server figures out that the client has a stale view. If client sends 4 as client intelligence, what is the server gonna reply in the topology change header? Is it gonna reply with no cluster info? or hash aware topology header? I get the feeling that we're trying to use client intelligence as way to signal that the operation sent is transactional: "Base on client's intelligence, the server should be able to determine weather these fields are present or not." and I think this is not correct. Let's leave client intelligence as it is and let's not try to give it a different meaning. Instead, let's use [tx_id length] to signal transactions. First of all, I think [tx_id length] [tx_id] should be part of the header since it's something common to all operations, rather than appending it at the end of the command where we store command specific information. On top of that, [tx_id length] can easily be used to signal a transaction. If [tx_id length] is 0, no tx is being sent. If not 0, a tx_id follows and hence the operation is transactional. Cheers, On Jul 20, 2010, at 11:45 AM, Mircea Markus wrote: -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache