Hi, (I currently have very little time, so here are just a few thoughts. I may not have time to enter a discussion about this.)
But what if something bad happens? In your scenario, assume that Bean B updates a resource in the context of transaction T'. This means that transactional locks are held on the resource, until T' is either committed or rolled back (or, horrors, a heuristic decision is made). Now Bean B returns, but before the server of Bean A can enlist subordinate transaction T' in transaction T, the server of Bean A crashes. Since the server of Bean A did not enlist subordinate transaction T' in transaction T before it crashed, it does not know about subordinate transaction T' at all when it comes back up and does transactional recovery. So the server of Bean B will never be consulted by A when it does recovery, and T' will never be committed or rolled back. This means that the transactional locks of the resource that Bean B updated will not be released until a heuristic decision is made to end transaction T'. But another optimization may be possible: Each of the two phases of the commit protocol may be done in parallel: Consider transaction T who has enlisted subordinate transactions Ta, Tb and Tc. When T is committed, it may do the network calls to prepare() Ta, Tb and Tc in parallel. And once Ta, Tb and Tc have all replied, and T has decided to commit, the commit() calls to Ta, Tb and Tc may again be done in parallel. If network latency is the only significant delay, this may reduce the time for committing T to a third. But if the prepare() and commit() are done over a blocking protocol (like RMI), seperate threads will be needed to do this in parallel. Best Regards, Ole Husgaard. Anatoly Akkerman wrote: > > 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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
