Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm
2. supporting corba etc. I realize I am not entirely comfortable with the client interceptors, and I notice that they are not really used in the local proxies. I don't think my idea of using the client interceptors inside a corba invoker will work, because there will be no way to simulate a client environment. So I'm basically abandoning my idea of always using the same client interceptors for all clients including local, remote, and corba. I think the current client interceptor stack configuration system may be lousy and need redesign, but that is sort of a third question. I think it should not be tied to the invoker but to local/remote/corba choice. The fact that all client interceptor stacks today are identical supports this view. How about: server side interceptor gets back the functionality of suspending transactions that are not needed (for not supoorted and requires new) client side interceptor for remote client does this also, to avoid creating unneeded branches. Local clients won't need the client side tx interceptor. The corba clients will continue creating branches based on the corba transaction policy, and we will import all such transactions that arrive via corba immediately. The server side tx interceptor may suspend these tx in the case of notsupported and requiresNew. There's nothing we can do about the remote corba tm creating unneeded branches, and the simplest way to deal with them is simply to import them so when a prepare/commit/etc request comes we just let our tm deal with it. ----------------- (in reference to Hiram's comment) On the client side, I need 2 pieces of functionality: a tx-support aware interceptor per remote object (ejb name, not instance) and an xaresource per remote jboss server. I'm still convinced this is by far the simplest possible implementation for dtm. I think writing the xaresource as a transport-level interceptor will have many many simplifying advantages, but it is not necessary, only about half as complex as my previous solution. It could be written once and plugged in some other way, but I don't see the point in using an inferior architecture to an interceptor stack. Thanks david ------------------------------------------------------- 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
