|Class org.jboss.ejb.MethodInvocation is also
|changed. A class variable referring to an
|instance of the TPC Importer is added. This
|will be filled in by an instance the first
|time needed. An extra constructor that takes
|a TPC is added, and used when the MI is created
|from a RMI. Internally in MI, the TX and TPC
|are seperate private variables. The method
|getTransaction() is changed so that if the TX
|is null and the TPC is not null, the TPC Importer
|is called to create a TX. This TX is set in the
|MI and returned to the caller.
|This way, changes are transparent to the container
|and its interceptors. Only the container invoker
|has to use the new extra constructor when creating
|a MI from a RMI.
|And this also means that a transaction will *not*
|be imported unless it needs to (MI.getTransaction()
|called). When we get distributed transactions, the
|import can be expensive. Currently, the TX
|interceptors call MI.getTransaction() every time,
|but changing them to do it only when needed should
|be easy.
Ok, I believe the "import" can be even more lazy. If you are talking about
a real "import" as in an association with the thread then the
MI.getTransaction() is a bit strong to do that. Remember that the existence
of a transaction is only needed in the MI as long as you are in stacks that
are "MI-type" aware. Only when you leave these stacks (say to call an
instance) do you have to associate the transaction with the thread (import)
and pass that on.
In other words. Unless you give another meaning to "import" I believe the
"import" is something container configuration specific and that your "TPC
importer" doesn't belong in the "message" it is a worker on the assembly
line not a "central MI feature". Factor it lazily is my recommendation.
|Another thing that binds JBoss to the current
|native TM is the use of the non-JTA methods
|associateThread() and disassociateThread. As a
|proparation for avoiding these calls, I've
|implemented the JTA methods suspend() and
|resume(). When JBoss has been changed to use
We have been there before and it is a mistake. suspend() and resume() are
methods ON THE TRANSACTION (suspend the transaction and resume the
transaction), suspend association and resume association are ENTIRELY
DIFFERENT semantics, they suspend and resume teh association but NOT THE
TRANSACTION. It is a spec missread.
In fact the interface is there to "debind" JBoss as you can use whatever is
needed to reassociate with the thread under that generic interface (in JOnAS
it was the "setPropagationContext" something that couple the idea of your
TPC and the association at the same time).
|
|I am currently testing these changes, and unless
|anybody have objections or questions, I'll commit
|this in a few days.
|
Other than that keep it up!
marc
|
|Best Regards,
|
|Ole Husgaard.
|
