|It does make sense but here is what I don't particularly like about
|it, tell me if I'm wrong.
it's not as bad,
|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 is not correct in the case you are serializing the TX you are talking
about the class description ("org.jboss.tm.TxSerializable") and the content
of the serialization which in your case is that int you are talking about.
The client and server already have the class definitions so if you are
thinking about that it doesn't work this way if you already have the classes
on the target.
|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).
yeah... serialization is serialization and staying away from it *altogether*
is the way to go (fundamentally speaking really, fuck distributed
transactions for 5 years to come) and it won't cost that much more.
|Low bandwidth connections to server is, perhaps, not on your agenda but it
|is something we are thinking about.
Again it is not that bad, really (plus you can just do the serialVersion
thingy) and it is less important than having a transparent pluggable
architecture which it is *everywhere* right now *but* the transactions.
Ok?
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
