Hi,
Picking up an unresolved issue on an old thread.
marc fleury wrote:
> 1- TPC IMPORTER
> It doesn't really belong there.
>
> MI IS A REPOSITORY OF DATA FOR THE INVOCATION. IT IS NOT THE IMPORTER OF
> TRANSACTIONS.
>
> About the only thing I believe is elegant in this call is the "java:/"
> context lookup to get the TPC importer. It is elegant but silly. The
> container tx should really be the place where we import this call... and the
> container should not have to lookup the context (thank you very much)
>
> In any case we could rethink that structure the Tx stuff needs rework it was
> sucky (also the author of this call should recognize himself, don't worry I
> will rewire this crapola but do me a favor and sign your deed the next time
> you do it :).
I (kind of) agree that importing the tx does not belong
in the MI.
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.
That means that we cannot do the TPC import in the
transaction interceptors.
I guess the same argument goes for optimized local
calls.
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.
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. (First a
callback to originating transaction service to register
the local VM as a XA resource, and later a prepare()
call that just returns a read-only vote.)
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.
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.
What do you think?
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
