On 20 Jul 2010, at 14:07, Galder ZamarreƱo wrote:
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.".
Infinispan batching is a way to execute local transactions.
cache.startBatch(); //start local transactions
//do stuff
cache.endBatch(true); //this would commit/rollback the local transaction
Batching functionality (i.e. local transaction) is implemented by starting a JTA
transaction(i.e. global transaction) within BatchingInterceptor.
Transactionable clients doesn't sound very well to me. I'd go for
'transactional clients'.
+1
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.
Good point. Thinking some more we can pool the
connection to the server so that we won't keep a TCP connection for the entire
duration of the transaction, which would be bad.
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.
I've just started t o like 1 more as well :) Just to clarify one
thing with 2: the tx would reside on one server only. If the prepare lands on B it is
forwarded (through something like a FrowardCommand) to C where it would be executed. More
complex though.
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?
XAResource on
the client won't confirm the transaction commit to the
TransactionManager(XAResouce.commit would throw an XAException with an specific exception
code). From there on it is with the TXManager.
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.
Yes, I agree.
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,
but ping, but ping is not really relevant :)
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.
Point taken. This flag is in trunk and is ignored for now, as we've
discussed.
Thanks a lot for the feedback, this changes the design significantly. I'll update the
doc and let you know.
Cheers,
On Jul 20, 2010, at 11:45 AM, Mircea Markus wrote:
> Hi,
>
> I'be just added a design draft for transactions over hotrod[1]. Feedback
appreciated!
>
> Cheers,
> Mircea
>
> [
1]http://community.jboss.org/wiki/TransactionsOverHotRod
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
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