Hmm, what speaks against resource managers being remote objects and a few transient threadLocals inside Transaction that contain the private inner-VM state? The problem that I see with serializing just the Xid is that you need "the single central TransactionManager" in your server farm that is able to register and batch all the transactions, even if they are quite local. In the above approach, we could take the VM/TM that has initially started the transaction as its manager which should be more scalable than the traditional OTS way of doing that (which IMHO originated in the lack of serializable objects ;-) Comments? CGJ -----Urspr�ngliche Nachricht----- Von: Aaron Mulder [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. Juni 2000 00:11 An: JBoss Developers Betreff: [jBoss-Dev] TransactionImpl - How serializeable is it? Well, Transactions are supposed to be serializeable according to the JTA spec. The reason they give is to support JNDI. I don't really follow - couldn't you have an object factory or something? I guess I just don't understand why you'd ever want to serialize a Transaction. It seems to me to be pretty private between the TransactionManager and the Container - and those will always be running in the same VM, right? I suppose you may want to have a global transaction that involves several app servers, but I would think you'd serialize the Xid rather than the Transaction itself, if that was the goal. Further, looking at the TransactionImpl in jBoss, it's not clear that it really will serialize. The typical use of transactions has to be to manage database connections. The Transaction has a reference to the XAResource, the XAResource has a reference to the java.sql.Connection, and the Connection is generally not serializeable, so the TransactionImpl serialization would fail, right? What am I missing? Aaron
