marc fleury wrote:
>
> btw I think more about this and we really have 4 points of entry with
> threads...
>
> 1- normal invocation (enters through container invoker)
> 2- commit through Synchronization (session and entity)
> 3- passivation (independant thread)
> 4- time outs
>
> on ALL these 4 entries the context class loader must be set, the error we
> are seeing is in 2 but all the others must be done (well 1 is done at
> least).
>
> Simone can you look into 3 (do
> Thread.currentThread().setContextClassLoader(container.getClassLoader()) or
> something like that, before leaving the thread do the rest since the
> ejbPassivate WILL work on the bean and need that visibility on its classes).
>
> Ole :))) we still have some issues with the timeouts and I do believe that
> some calls will end up on the instance (yes?no?) if yes or if any clean up
> work needs to happen on resource that are client specific then we need the
> same CL to be set on the thread.
Currently timeouts is only used for transaction timeouts.
When a transaction timeout happens, a rollback is done.
This rollback is like any other rollback except for one
important issue: It can happen at any time, asynchronously
to other threads. This is why I've changed some of the
code that uses transactions to catch IllegalStateException.
Checking the transaction state first won't do as the timeout
could happen after checking and before calling a Transaction
method.
All the callouts from the transaction timeout rollback are
done asynchronously. These are in two categories:
1) Transaction synchronization. You have already changed this
to set the right classloader. Please note that currently
beforeCompletion() is called on rollback too. I am not sure
that this behaviour is what the JTA spec says (its a little
unclear), but Oleg needed it, and I do not think that it
disturbs much (a few ejbStore() calls that will be rolled
back).
2) XA resource calls. These do not end up in the bean, so
there should be no classloader problem here.
And since Minerva XA resources are only associated with
a single transaction at a time and we already sync on the
transaction in TxCapsule, the Minerva XA resources should
be safe.
A transaction timeout could also happen while a bean invocation
is active. Not sure what should be done here; JTA says nothing
about it.
Probably any transactional resource used by the bean code after
the rollback should throw an exception at the bean.
Best regards,
Ole Husgaard.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
