ok,
first the implicit explicit difference must be explained clearly.
explicit means that it is something you pass with the invocation as
parameter somewhere (e.g. the tx is passed "explicitely" in the method
invocation, you can do a mi.getTransaction()).
implicit means that it is not passed explicitely (you cannot do a
mi.getTransaction(), you have to go to the TM and the TM keeps thread
association and can "implicitely" deduce what Tx is associated with you and
your call.
So you actually mean that "we must associate the tx implicitely"... in clear
your message is actually why implicit tx *is the only way* to make it work
:)
Ok onto what you are saying...
|Why? Because code in between the container invoker and the instance
|invocation needs the tx to be set in the tx manager. I am specifically
|thinking about the synchronization interceptor. If the state of an
|entity instance needs to be loaded, then a JDBC call is done. The JDBC
|pool checks for tx in the TM, but if the caller of the entity used a
|real RMI call then the JDBC pool won't see a tx *even though there is
|one being sent along the interceptor chain implicitly*.
<ahem> look at the TxInterceptors they *already* associate the tx
implicetely </ahem>
so in fact the bug we were seeing yesterday is a result of that... that the
minerva pools see a tx associated with the thread and take the blind
decision (and wrong) to rollback our transactions like a big boy... I truly
believe that this association is in fact dangerous because the little
knowledge is the pool is dangerous... let the One With The Knowledge (tm)
(the container) take the decision for it's services on whether to rollback
the transaction or not.
but i digress (I am saying that it is not such a good thing if services are
bad behaved).
In any case please read the code you will see
1- that's what we do already
2- it's not such a good idea
The thing we don't set is the transaction on the context (explicit sphere, I
know you like it) until we actually invoke the instance. Orthogonal... I
have a problem with that now for other reasons, namely that an instance will
travel down the line of invocation with no Tx in the context, only in MI,
and another thread comming in will see "notx" and default to the lock... We
saw that behaviour under heavy load, it is innocuous and it still works
since an "unlock" on the ctx still refreshes everyone. <cough>read the
code</cough> but it is not proper.
regards
marc
"I woke up this morning,
and the queen was dead!"
-- Morel, "true" --
