We have one transaction that is basically acting as a delegate manager. In xMII 11.5, we cannot call another transaction dynamically (i.e. you have to set the transaction name in the Configuration block - you can't set it in the Link editor), so we have to use a switch/case to delegate to the appropriate handler. Each handler performs a number of actions including calling other transactions. Two different delegates may call a common transaction, but there is no recursion going on here - yet.
Now, in one execution path, we have a need to call the top-level delegate manager again. If we call it, we're recursing. It's not unbounded recursion - it will only happen once. By this I mean that this execution path cannot happen twice resulting in infinite recursion. However, even though we only call the same transaction twice, xMII consumes 100% CPU and the heap grows until it dies. This result is classic for infinite recursion, but we're only calling the delegate manager twice at most. Could there be something in the way that xMII loads a transaction and sub-transactions that could be causing a recursion issue?
Also, in a non-recursive scenario, what all does xMII do when it loads a transaction? Does it try to load the entire sub-transaction tree? Does it use a lazy-loading scheme where a transaction is loaded only if executed? e.g. will it load all the actions/transactions in both paths of an "if" conditional?
In a recursive scenario, if a transaction is loaded again, does it recognize that it's already been loaded (and loaded its child transactions) and not reload them? Or does it load them all again?