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. >> >> 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 > >
