|When we get to support IIOP invocations, the CORBA
|invocation transport layer automagically imports
|incoming TPCs, and we never see a TPC that we can
|import.
Yes
|That means that we cannot do the TPC import in the
|transaction interceptors.
|I guess the same argument goes for optimized local
|calls.
it is a question of context, who knows what the transport protocol is and
who knows what the local transaction monitor is...
|Always importing an incoming TPC in the invocation
|transport layer (as CORBA does) is simple, as we
|never have to consider TPCs, or how to import them.
then the tl need to know about the tx that a given container uses... the
simplest is to have an intermediary form in the MI
transport specific TPC => MI.getTransaction (JBOSS ONLY) => TM specific TX
|However the import may be costly in a distributed
|system, and in some cases we do not need to import
|the transaction because it will never be used in the
|invocation (TX_REQUIRES_NEW for example). In case of
|a distributed invocation of a TX_REQUIRES_NEW method
|with a transaction context never used, we can save
|at least two network round-trips per transaction, if
|we can avoid importing the incoming TPC.
sure, if we can save the last step it is good
|The TPC import in the MI is simply a hack I did to
|postpone the TPC import until we reach the TxInterceptor
|where we know if we need to import the transaction, thus
|enabling the above optimization.
yes, I see that now, it is ok, it is called XP, put something we need in,
then rework it :)
|I am not religious about this, and if you think so,
|I'll take it out again, and do the TPC import in the
|invocation transport layer instead.
|Going that route also has its advantages, as it will
|simplify the code quite a bit: For example, it means
|that the MI does not need to know *anything* about
|transactions, as we always would have
| MI.getTransaction() == TM.getTransaction()
|and MI.setTransaction() would be superfluous.
BUT WE WANT THE MI TO KNOW ***EVERYTHING*** ABOUT THE TRANSACTION IT
PARTICIPATES IN.
Ok I believe we should take the tpc out of there, but rely on the mi to get
the pointer to the tx
That is a mistake a lot of the new readers of the code make. We want to
keep the pointer to the tx INSIDE the MI. The reason is that it is much
faster and the TM association is the only way ONLY when we are going through
interfaces that do not propagate that context (then we need to rely on the
thread association). So.. leave it there, trust me, USE THE MI TO CARRY
THAT TX.
See the MI is a repository of information about the invocation going on.
As we move to webservices (even if they don't propagate tx) we want the
different MBeans in the JBOSS General Purpose Architecture to pass around
message with all the information in it, including the tx they are
participating in, I don't want to go to the tm every time and look up a
thread map, so do not rely on anything implicit and the TM association is an
implicit one.
|What do you think?
good and bad, refactor the tpc out, the MI must remain clean, but don't
factor the tx out, even if you can...
:)
marcf
|
|
|Best Regards,
|
|Ole Husgaard.
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
