> > Just the same way, we are talking about a "static" field for the TPC > exporter and importer. The TPC importer is in the readObject and creates a > local transaction object. > > The design for the transaction right now barfs everywhere, the transport > layer has to be aware of it (ugh!) when really the transport layer should > only be aware of serializable objects. > > in fact just have the Transaction lookup the JNDI entry for exporter and > importer, that would be super sweet... neatly packaged and confined. It > sort of looks bad to have an absolute unified layer and interceptors and all > the modern patterns at play and then a fat "if transaction Manager bla bla > bla then bla bla bla" in the middle of your transport layers. > > Does this make sense?
It does make sense but here is what I don't particularly like about it, tell me if I'm wrong. I am mostly concerned about remote clients for whom the serialization actually happens. If we end up serializing this Tx Proxy with its Invoker that would actually ship only the TPC which it extracts, we would have to ship at least 1 more class on the wire (the Proxy). I don't know actually how serialization happen in terms of the class code being shipped, in which case the code for the Invoker would get shipped as well? Having a TPC and only serializing it is more lightweight (in fact, in my rewrite of Tyrex plugin I am only sending an integer, boolean and a few strings, besides other attempts to improve distributed performance). Low bandwidth connections to server is, perhaps, not on your agenda but it is something we are thinking about. Anatoly. > > marcf > |> > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
