Hey
marc fleury wrote:
> 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
> :)
Duh, yeah 8-) Sorry 'bout that.
> |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>
Oooh, well that's just smashing innit'. Oh well, I'll just shut me'
stupid mouth now, thank you very much 8-)
> 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.
Indeed.
> 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
So it would seem yes :-)
> 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.
Gotcha.
Over n' out.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
