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.