Hi, Sorry for my late answer, I am a bit busy these days.
marc fleury wrote: > I never realized this until I was working on the client interceptors > yesterday late at night. Our transaction object requires an external person > to serialize itself. Namely the extraction of the transaction propagation > context is done outside the transaction itself. Using external persons (TPCImporter and TCPFactory) in the transport is a conscious design decision. 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. 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 we would have to use a TransactionManager wrapper that returns our Transaction wrappers instead of Transactions. 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. But this would also mean a slower JBoss server for those who do not distribute their transactions across VMs at all. > This is a problem as it means that whoever is doing the serialization (in > our case the JRMPInvoker layers) MUST know about the TM and that means we > need to set the transaction monitor on them somehow. It works. Whoever is doing the serialization (and deserialization) ought not know about the TM. 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. > If however we set the static entry on the Transaction implementation then > the writeObject(Stream) call could take care of it own serialization (by > getting the TPC and replacing the Tx by the TPC on the stream and that would > be that... I think it would be a bit more self contained from a design > standpoint. I agree. 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. 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. 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. Also, this is only a problem for transports that do not directly support transaction context propagation. When using the IIOP transport (and most other transports that directly support transaction propagation) (Java-)serializing the Transaction would not work if we want to be compatible on the wire. Best Regards, Ole Husgaard. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
