|IMHO this is another design flaw in JTA: The methods |in TPCImporter and TCPFactory should belong in the |TransactionManager. Without them, the transport needs |to have special knowledge about the transaction server |to be able to move transaction contexts across the wire.
Yes that is a weakness |Not that i really like this design. When i came up with |it, I did a lot of careful thinking and studying of |similar code trying to find something better - but I didn't. | |The alternative would be to use a Transaction wrapper that |knows how to serialize itself, and to produce these wrappers Just put the import export code in the serialization pass it the JNDI names for importer exporter (or just the TM as you propose) |we would have to use a TransactionManager wrapper that |returns our Transaction wrappers instead of Transactions. No just extend the transaction to do the correct behavior |So while the serialization in the transport would look a |bit more beatiful, the cost would be that _every_ access |to transactions in the server would have to go through |a wrapper. not so, right now the pluggability is broken on the client side due to this hardcoded transport dependency. No need for a wrapper just an extension, either way the price is nothing. |But this would also mean a slower JBoss server for those |who do not distribute their transactions across VMs at all. nope |Whoever is doing the serialization (and deserialization) ought |not know about the TM. correct |The only object needed to serialize the transaction is an |instance of org.jboss.tm.TransactionPropagationContextExporter, |and the only object needed to de-serialize is an instance of |TransactionPropagationContextFactory. |TPCImporter has a method that takes an untyped deserialized |object and (tries to) convert it into an instance of |javax.transaction.Transaction. |TPCFactory does the opposite, it has a method that takes an |instance of javax.transaction.Transaction and returns a |serializable object. |Both the TPCImporter and the TPCFactory can be looked up |in JNDI after the TM MBean is started. well then that is the call we need in the write/read, no price to pay for the other and none of that nonsense. |> be that... I think it would be a bit more self contained from a design |> standpoint. | |I agree. And most importantly : for people who DON'T use the transactions we can remove it cleanly (pluggable, today it isn't and it is the only one). |But i cannot see how this could be done without either: |1) Using a wrapper for Transaction and TransactionManager | that all local transaction access in the entire server | would have to traverse. I don't agree, our native one can use the same object. |or |2) Hacking/patching every JTA implementation we want to use | in JBoss to add the extra functionality to the Transaction | implementation in that JTA implementation. The wrapper is for say Tyrex distributed transactions, it should really be a spec requirement that transactions are serializable (isn't that the case in JINI?) In any case stop talking about the "the cost of a method invocation in memory" when we are talking about distributed transactions, that price is 1 in a million (if not less :) |I agree that the extra conversion step in the transport is |more ugly than just letting serialization/de-serialization |do its work - but we should carefully balance this against |the cost of the alternatives. it's not only ugly, it breaks pluggability. marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
