On 11/6/11 9:12 PM, Kiran Ayyagari wrote:
Hi Dev,
Currently the interceptor chain heavily depends on the current
operation context stored in the InvocationStack as a
threadlocal variable, but this poses a problem for transaction
handling (if we use threadlocal transactions then
two different requests might get processed by the same thread
leading to using the same transaction)
Not sure, as a request will be fully processed before another request
can reuse the thread.
Earlier we had one big hurdle in the form of chain re-entry to
achieve this, but now we have almost got that removed
(there are still some more (<4) but will remove them in the coming days)
I have checked some of the inner operation, and there are cases where we
need to re-enter the chain: when modifying the schema. A modification of
the rootDSE attributeTypes value, for instance, will also lead to a
modification of the cn=schema (or is it ou=schema ? never remember...)
partition, and this will be done with a add or delete operation call.
We may get rid of such re-entrant operation, except that we will lose
the logging of a revert operation in this case. That would be a great
loss, IMO.
I would like to make the interceptor chain completely stateless by
avoiding the use of InvocationStack, so that
we can inject a transaction handle directly into the OperationContext.
The chain should be stateless, I'm not sure we need the InvocationStack
anymore, but I'm not sure this is really connected to the fact that we
use threadLocal, or not.
Again, there is one thing which has to be taken into account before we
remove the InvocationStack, is that we can revert a complete schema
modification, which implies a double call to the chain (an in this case,
I wonder if we don't need to keep the reference to the parent call in
the second call).
To be investigated further.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
