[ApacheDS] Removing the InvocationStack

[Alex Karasulu <ak...@apache.org>]

Hi all,

I'm thinking about replacing the InvocationStack which is used to manage a
Stack of Invocations per Thread.  This was intended to circumvent operation
recursion due to poorly designed triggers and stored procedures and to be
able to differentiate between direct operations and those performed as a
result of them.  The idea was to devise strategies to halt execution if for
example the Stack got too large or cycles of operations were detected.
NOTE: this has nothing to do with dead lock detection and everything to due
with detecting chain recursion.

Take for example the following operations ordered by chronology as a result
of a direct delete operation:

(1) D[delete]
(2) I[lookup]
(3) I[modify]
(4) I[lookup]
(5) I[add]

D = Direct, I = Indirect

Here, we can imagine a delete operation which raises a trigger that executes
a stored procedure.  Inside the stored procedure a lookup maybe performed on
a group containing the entry to be deleted, then a modify operation may be
performed on the group.  Then perhaps another stored procedure is executed
by another trigger to lookup before adding the deleted entry to some trash
bin area.

For this scenario the stack may looks like so at various points in time:

                        | 2 |      | 3 |     | 4 |      | 5 |
| E | -> | 1 | -> | 1 | -> | 1 | -> | 1 | -> | 1 | -> | 1 | -> | E |

The top of the stack represents the current operation in a chain of
operations resulting from a direct operation.

This InvocationStack is a real pain to work with.  First of all it uses a
static method to access Stacks which will cause issues when running in
containers with different classloaders.  Secondly it no longer stores
Invocations since these objects were removed during the course of
refactoring.  It now stores OperationContexts in these Stacks instead of
Invocations with JNDI Contexts.

I'm thinking of removing this completely and making OperationContexts have
forward and reverse referrences to their parent, and child contexts.  In
this way an OperationContext represents a node in a doubly linked list.
Also I'm thinking of making OperationContexts act as a factories for other
OperationContexts.  This way OperationContexts can create indirect
OperationContexts which can inherit their session object and other objects
they need on creation while being referred to by the creating
OperationContext and vice versa.  Incidentally, the linkage in this doubly
linked list of OperationContexts would be managed by the InterceptorChain or
the factory method which ever is best for synchronization.

I'm going to start working on this in the big bang but I thought I better
let people know about it since it's a big shift in what we had before.  I
think with this change we're probably done and ready to pull out the JNDI
code, then clean up the way packages are organized to close up this big bang
effort.

Thoughts?