Hi,
I've been thinking of how one could reduce network traffic in distributed transactions. This is a simple scenario of what happens in a DT: client calls Bean A which calls Bean B Bean A and Bean B live in 2 distinct servers (VMs) when client calls Bean A a transation T is started when Bean A calls Bean B, T is propagated to Bean B. According to OTS, when T is propagated to B's server, a subordinate transaction T' is started in server where Bean B lives and T' registers itself with the Coordinator for transaction T as a new Resource. This results in an additional network connection to A's server. (Since Coordinator for T lives in server A) When call to Bean B returns, T' is still present in B's server. Only when the call to Bean A returns to client and T is committed, the coordinator for transaction T does a 2pc and calls all subordinate resources (including T') to prepare() and then commit(). This is 2 additional network calls. >From this example, it is aparent that T will need to know about T' only after call to Bean B returns, there is no need to know about it earlier. Unfortunately, the B's server will call the Coordinator as soon as T is propagated, when T' is created and registers itself as a subordinate. To alleviate this problem, TPC importer can fake successful registration but delay the actual registration until the return of the call to Bean B. The registration can be propagated along with the _result_ of the call to bean B, since this is a network connection to the server A anyway. This way we can cut one network connection. This raises an issue of adding payload not only to the Invocation itself but to the return from Invocation. Say we can introduce InvocationResult which can contain arbitrary payload along with the actual result of the invocation or exceptions that occured during invocation. Stripping the payload can be done by the proxy-side interceptors. In case of distributed transactions, an interceptor in the Proxy (client-side interceptors are a very smart idea :) for Bean B will perform delayed registration of subordinate transaction T' when the invocation to B returns, by extracting registration info from the payload of InvocationResult. The introduction of InvocationResult and payloads will affect performance of only unoptimized calls, since now along with the invocation result we would ship other stuff, like profiling info, etc. Supposedly, if the payloads are not excessive, this will not affect even the unoptimized calls accross the network, because latency is likely to dominate bandwidth constraints. ------------------------------------------------------------------------- Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 ------------------------------------------------------------------------- _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
