On Mon, Nov 7, 2011 at 12:14 AM, Selcuk AYA <[email protected]> wrote: > On Mon, Nov 7, 2011 at 2:14 AM, Emmanuel Lecharny <[email protected]> wrote: >> 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. > > If the concern here is about requests due to chain re-entry > operations, actually these internal operations should be part of the > same transaction I think. > no, it is about two different (client) requests (not the internal OperationContextS created as part of processing a single operation/request) >>> >>> 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 >> >> >
-- Kiran Ayyagari
