Hi, I am not sure if I understand you.
Do you want all instances of javax.transaction.Transaction floating around the server to be instances of a JBoss-specific extension of this interface that knows how to serialize itself? marc fleury wrote: > |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) If you do not want it in the Transaction implementation, as an extension to JTA, where then? > |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 We can only extend our own TM, for all others we would have to use wrappers for all instances of Transaction and TransactionManager. > |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 Well, not if we hack our own JTA implementation to avoid using a wrapper, and use that. But how about all the other JTA implementations? > |> 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). I don't think that the current design breaks pluggability. See below. > |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. Yes, we can change our own to avoid using wrappers. But only our own. > 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 :) The wrapper would be for _any_ JTA implementation that is not hacked to avoid the wrappers. > |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. Currently, the TPCImporter and TPCFactory use a null TPC to denote "no transaction". It shouldn't be a problem to change the invoker to always use a null for the TPC on the wire if TPCImporter and TPCFactory have never been set. Otherwise (if you want to save the serializabled representation of null on the wire when no TM is plugged in), you are in effect changing to wire protocol when adding/removing the TM plugin. If no TM MBean has been started, looking up the TPCImporter and TPCFactory in JNDI should throw an exception. Catching this exception and ignoring it shouldn't be a problem. Or have I misunderstood something here? I am a bit worried if you are too blinded by the JRMP transport code (that i assume you are working on right now). I think this is the only object invocation transport that does not natively support transactions, and thus the only one where the TPCImporter and TPCFactory are really needed. Also, I think the JRMP transport is the only transport where (Java-)serialization of the transaction would make sense. IIOP, on the other hand, natively supports transaction propagation, and doesn't need TPCImporter and TPCFactory. Also, IIOP doesn't do (Java-)serialization, at least not for the propagated transaction. The cost of an extra method call due to the use of a wrapper may not sound of much, but the methods of Transaction are used quite a lot. Not just in the interceptors, but also from resources. And you want to incur this overhead everywhere in the server just to avoid a few lines of uglyness only needed for the JRMP transport? (Agreed, we could hack our own TM to avoid the overhead.) Best Regards, Ole Husgaard. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
