Man,
heavy Tx stuff for a Sunday, I do love "Web-Txs" though and I believe few
people *get* it.
Ok I also have a 20 month toddler :) I am playing with her... any typo on
the keyboard is my daughter :)
|The TransactionPropagationContextImporter does
|no thread association at all. It has only one
|purpose: Given a transaction propagation
|context (a serializable Object instance
|suitable for transmitting across the wire),
|it must deliver a reference to an instance
|implementing javax.transaction.Transaction
|that represents the transaction in the local
|VM. The interface has a single method:
| public interface TransactionPropagationContextImporter
| {
| public Transaction importTransactionPropagationContext(Object tpc);
| }
Fair enough you scoped it right, then the import which is just a creation in
the local VM of a live Tx can be done whenever.
|Depending on the actual implementation of
|this interface, the transaction may or may
|not really be imported. If the same
|transaction has already been imported into
|the local VM, it would make sense to avoid
|the slow network calls involved with the
|import and just look up a local Transaction
|instance in a map. The current in-VM DTM
|always does this.
yes correct, why do you say "would" it is still the case isn't it?
|I have a reason for doing this in the MI
|instead of directly in the RMI: If the
|transaction is never used, there is no need
|to import it. With a real DTM, the import
|includes expensive (in terms of latency)
|network calls to register with a transaction
|service. If we can avoid it, we may get
|a significant performance gain, but we do
|not know if we can avoid it until we are
|in the interceptor chain.
wait, I am confused. I wouldn't expect you to do it in the RMI NOR in the
MI, but in the interceptor chain. I haven't actually looked at your code,
but from what you explain I envision a "TxImported" flag in the MI. The MI
is really a "message" an XML message of sort if you wish! it says "method,
params, return object, tx, principal" I don't feel it should be aware of the
surrounding "assembly line" logic. I guess it is just "packaging" but if
you can factor that out then so much the better. MI remains a
"serializable" object at heart, or I should say and externalizable object at
heart. I was never a big fan of the MI/RMI distinction introduced for
"portability", I mean the default layers can use MI...
|To put things into the JTA terminology:
|The TPC Factory and Importer interfaces
|define the communication resource manager
|(CRM) that the JTA does not specify
|except for mentioning JTS for
|interoperability (standard wire protocol).
|In JTS, package org.omg.CosTSPortability
|does the job of the CRM. The two
|interfaces I made for this are a little
|simpler, as I prefer to keep things simple,
|and we generally do not need the complexity
|introduced by CORBAs Dynamic Invocation
|Interface. In the few special cases where
|it might be needed (like CORBA deferred
|invocation with transaction contexts under
|a non-JTS transaction service), it should
|be possible to add a little extra code to
|the non-JTS TM support it. And we won't
|even have this problem until we have a
|non-JTS distributed TM capable of exporting
|transactions to the CORBA OTS domain.
Ok so you create a Tx representation in the local TM through portable
interfaces... Corba introduces so much complexity to insure "portability" :)
|
|But still, no thread association here.
|That is up to the application server and
|comes below:
|
|> |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.
|
|Well, judging from code comments, we do not
|quite agree here. I am just not sure why.
|Guess this happened before I got involved with
|JBoss.
Most of the comments in the TM are mine :)
|> 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.
|
|I think that the method names suspend() and
|resume() are misleading:
|Reading JTA 1.0.1, section 3.2.3, it is clear
|that thread association *is* done in these
|methods.
Yes, suspend and resume "suspend" the Transaction AND disassociate (of
course). But a "disassociation" does not suspend the transaction. Do we
agree on that?
So do not use "suspend" to JUST disassociate since it propagates to the RM.
(that is how I spotted the problem with JOnAS)
|But given these method names one would think
|that transaction suspension and resumption
|is also done here. This is not really the
|case, as JTA 1.0.1, section 3.2.3 specifically
|says that the application server is responsible
|for calling XAResource.end(TMSUSPEND) and
|XAResource.start(TMRESUME) on the right
|resources at the right times.
|
|JTA 1.0.1, section 3.2 says: "The
|javax.transaction.TransactionManager interface
|allows the application server to control
|transaction boundaries on behalf of the
|application being managed. For example, the EJB
|container manages the transaction states for
|transactional EJB components; the container
|uses the TransactionManager interface mainly to
|demarcate transaction boundaries where
|operations affect the calling thread's
|transaction context. The Transaction Manager
|maintains the transaction context association
|with threads as part of its internal data
|structure. A thread's transaction context is
|either null or it refers to a specific global
|transaction. Multiple threads may concurrently
|be associated with the same global transaction."
|
Well at least we are further than we were with Rickard :)
Ok this sentence also clearly shows the separation between "suspend" and
suspend Association. Many thread can be associated to a transaction and you
can "suspend" the association on each one individually. Suspend on the
"transaction" would suspend teh "Global" transaction and of course propagate
to the other "local" associations.
"suspend" is a global notion on the "global transaction" whereas association
doesn't affect teh liveliness of the TM just the local VM association.
Thread association has no "web meaning" it just is an engineering trick to
propagate context by the thread.
in fact in general threads on the web are meaningless, they are "system"
objects.
What has meaning is the global transaction. Suspend and resume apply to
these, not the local ones.
|I cannot really read this as anything but:
|"Thread association done here".
I read as "Thread association ALSO done here"
|And since section 3.2.3 (about these two
|methods) also says "Thread association done
|here" and "Resource tx suspension is caller's
|responsibility", I find it hard to read the
|JTA spec any other way than "the method names
|are misleading", and "these methods do (almost)
|what the JBoss-specific thread association
|does".
hmmmm I think it is due to the fact that most people missread this (few
people understand TX). To me it is pretty clear. I did factor out the
"Thread association" as a portability layer in propagation context... you
put them back as one, in my opinion it is misleading.
|I think I am right here, but I may still
|misread JTA.
|If you think so, please let me know.
Well ok I wont' say you misread the global vs local scope of the operations.
btw that is why I love "Mark Hapner" as a spec writer, (EJB/JMS) local is
his building block... global notions are constructs... very powerful very
clean very clear... JTA and XA aren't as clear.
|Looking at some old JonAS source, it looks like
|these methods (in org.objectweb.jonas.jtm.Current)
|do the thread association and "some more":
|This "some more" is calling res.end(TMSUSPEND)
|and res.start(TMRESUME) on the resources from
|a private list of XAConnections that are
|modified in JonAS specific methods
|Current.addConnection(..) and removeConnection(..).
|
|So if we do not use these JonAS-specific methods
|for enlisting and delisting XAConnections and just
|do like JTA requires of the application server, I
|guess the JonAS TM should be OK with this when
|used in JBoss.
yes it WAS used in JBoss (I did the integration and this is when I
understood "suspend/resume" btw I did the same mistake, i.e. using them in
the first place)
|I guess I should add a few comments on the
|requirement of JTA that the application server
|suspend resources when a transaction is suspended:
|I am not really sure why this is required. When
|some component in the application server calls
|another component is such a way that a TM.suspend()
|is needed (according to JTA), any XA resource
|connections in the first component are not used in
|the second component, so an XA resource suspend
|should not be needed. At least this seem to be how
|JBoss works now. I wonder if this requirement is
|meant for some kind of resource connection sharing
|between conponents that I do not know about.
Sure, well lets' get it working and then we will worry about "research"...
first things first
marc
___________________________________________
"And on that note, get back to the program"
--Keoki --
___________________________________________
|
|
|Best Regards,
|
|Ole Husgaard.
|
