"bill.burke(a)jboss.com" wrote : Furthermore, it is completely idiotic and gay to develop a new and different interface other than JTA if I want to use two non-XA enabled resources in the same unit of work. JTA is a great abstraction and has very tight integration with things like EJB to make your life tons easier. The abstraction JTA gives is based on ACID transactions. You are proposing to break that abstraction. XAResources are the two-phase participants that can be enlisted in the transaction. Yes, I know you know this, but we're having a discussion here so it's worth pointing this out. Basically you are suggesting that we allow arbitrary enlistment of non-two phase aware XAResources within a transaction and break the protocol. I think that doing that within JTA is "idiotic and gay". Furthermore, at the moment all of this is academic as far as I am aware. We have no customers who need this. If some come forward, then we can look at the issue, assuming their scenarios cannot be addressed through some other way. anonymous wrote : | BTW, you're the same guy who tried to argue with me that JTA is useless when you have only one resource in your transaction. | Sorry, not me. Any good JTA implementation covers the 1-resource optimisation, so you don't get the overhead of 2PC. If I said anything it was probably that any good JTA implementation doesn't have to do a lot in this case. anonymous wrote : | Anyways, there is absolutely nothing wrong with using multiple non-XA resources in same TX if a) you can't make them all XA and/or b) more importantly, you are aware of the consequences. | On that we can agree. They MUST be aware of the consequences. anonymous wrote : Forcing users ,for the sake of purity, to refactor their applications when they are aware the problem exists is just plain pompus. | We're not forcing users. We have zero users who need this. The one user who thought he did was able to move to a two-phase approach. "for the sake or purity"? Well, in this case my definition of "purity" is that it conforms to the protocol and guarantees data consistency in the presence of arbitrary failures. Believe it or not, it is important for customers. Over the years JBossTS has, by itself, generated multi-million dollar revenues. So it has to work. People trust that it will work correctly. As I said above, if there really are customers out there who simply cannot do their work any other way then we can look at the best way to support this. But at the moment, I don't see the need. BTW, let's try not to make this personal. Believe it or not, but the exchange Weston and I had last night was very good natured. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989355#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...