First of all, the tpc is going away in jboss 4. You can look at the trunk invoker to see how things will be. The new system does all tx communication including prepare, commit, etc over the same transport as the invocation, and it is based on treating the target jboss instance as an XAResource and generating a transaction branch for it and transmitting the xid for that branch. On the target jboss instance, it uses the jca 1.5 XATerminator interface to control the tx end.
If you have some time, and especially when the dtm gets a little farther along, I'd really appreciate your looking at the new implementation. I've mostly been concerned with the new code rather than understanding exactly how the old code worked, however what should be happening is that the correct tpc factory is bound in jndi on the target jboss instance and is pulled back with the proxy. If you need several tpcs you'd need to set up several appropriately configured invokers on the target jboss instance. Any tpc factory will of course have to remove the tx from the invocation object since a tx should not in general be serializable. Hope this helps. david jencks On 2002.12.09 18:32:16 -0500 Anatoly Akkerman wrote: > > I am a bit unclear on how this stuff happens (looking at 3.0.4) source > > Tyrex plugin has stopped working because the client proxy does not seem > to be able to serialize the tyrex tx context correctly. The root cause > seems to me the fact that the JRMPInvokerProxy does not know about the > correct tx propagation ctx factory. The only place in code that I could > locate that calls setTPCFactory() on JRMPInvokerProxy is in the > constructor of ClientUserTransaction. This seems to break distributed > transactions via Tyrex, because if a bean in server A holds a proxy to a > bean in server B, that proxy is not picking up the right TPC factory and > tries to serialize the transaction instance itself, which is not > serializable. > > It seems the fact that the TPC importer and exporter are registered in > JNDI of the server that hosts the bean that has the proxy is never > utilized. Can someone explain this to me? In general, how would client > side interceptors become 'aware' of the presence of a TransactionManager > with its own TPCExporter when the proxy ends up in another JBoss > instance, while, the same proxies can also get used in a plain java > client which has no local TM and Exporter and the bean utilizes > ClientUserTransactions? > > I saw Marks comments in the code and remember the discussions about > making TXs serializable (let them handle serialization themselves). So, > what is the bottomline? Perhaps, once MBean server is mandated on the > client side, the interceptors will just lookup the TM in the local MBean > server. > > But in the meantime, what would be the right approach to fix the Tyrex > plugin for 3.x branch? > -- > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
