Hey
marc fleury wrote:
>
> I will take the brunt of the blame, it *is* due to the changes I did last
> week to the TxInfrastructure, had I read the TestBeans output closely I
> would have seen it. I will give a (friendly) slap on the wrist to rickard
> since the previous design relied on implicit information (Tx in ctx == null)
> that was ironed out with the MethodInvocation encapsulation of the
> information, and that was really easy to break (and I did). In such a large
> design you are bound to find little details like that.
>
> Bottom line is that a CTX is associated to the TX only when the locking is
> OK. So when a ctx joins a methodInvocation his tree of information (Mi.Tx
> and ctx.Tx) is valid.
>
> Ok the new stuff relies on solid encapsulated information and you try to go
> break it...
> I also changed the class significantly to implement a O(1) management of
> registration instead of the previous sync+map O(log) lookup. The names have
> been ironed out (valid state is called "isValid" instead of the cryptic
> "isSynch" (db is not synch however state is valid, misleading )). The
> isInvoked and isValid pair is encapsulated and we rely on that for our
> storage decisions.
Excellent catch, and excellent refactoring. Wish I had figured this out
myself :-)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
