recursion and loading sub-transactions

[Former Member]

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?

Thanks,

-tim

[Former Member]

Bill/Tim:

A few performance tips:

When you call a subtransaction repeatedly, be certain to uncheck reset state on each execution - this causes a reloading of the transaction. Be sure to add an assignment action at the start of your transaction to initialize/reset local variable and transaction outputs.

Invoking xMII as a web service (or via "Runner") is also a viable means for simulating recursion.

Don't be afraid to create custom action blocks for things that are very performance critical.

When creating your transactions, remember that xMII stores, with the transaction, copies of "reference documents" and other XML representations of data. Keep those as small as possible, and the transaction load time will be minimized. This is the reason for the "Limit Rowcount" button in the query action dialog.

Best regards,

Rick

[Former Member]

Thanks much for the tips, Rick. Does xMII use the reference document at all during run-time? We typically keep them in during development, then rip them out before we deliver to a customer. Perhaps a future version of xMII can add the concept of a "design time" and "deploy time" for transaction where metadata such as this can be ignored during run-time.

We'll try recursing through the Runner and see if we have the same problem.

Thanks again,

-tim

[Former Member]

Yes, it loads them (or tries to load them) at runtime. I would recommend leaving them in the deployment.

Actually, I had built a whole metadata subsystem into the product at one point (for query results, reference documents, really any type of structured data), but never released it. The main reason was to avoid the need to run queries to grab metadata information, which happens in a lot of places in xMII (not only design time, but even at runtime, since many of the applets are self-configuring).

- Rick

[Former Member]

We had the same situation where we wanted to call a sub transaction dynamically, but could not because the transaction name can not be linked. We solved it by writing a transaction which did the following:

Had 2 inputs, the transaction path/name, and the parameters as name/value pairs in an XML doc.

Assembled a URL to call the transaction (via Xacute Query), including the parameter mappings and parameter value assignments.

Used the URL in an XML Loader Action, linking the action output to the transaction output.

E.g.

http://localhost/Lighthammer/Illuminator?&Connector=XacuteConnector&Server=XacuteConnector&Service=&...withrecurse&MappedParamTarget.6=InPeriod&Param.6=Day-7to7*&MappedParamTarget.7=InRecordType&Param.7=&MappedParamTarget.8=InDeleted&Param.8=False&MappedParamTarget.9=InClassification&Param.9=&MappedParamTarget.10=InDepartment&Param.10=&Content-Type=text%2Fxml

Running a sub transaction this way doesn't appear to have any extra performance hit.

We also had problems with recursive transactions. We just decided we can't use them.

There is one more issue with sub transcations worth mentioning. If the transaction is reasonably sized, say 50 or more sequences, there seems to be a significant overhead in calling them. I have a transaction which calls 8 sub transactions. The time btween the beginning of the action and the start execution of the sub transaction varied between .5 and 2.7 seconds. This soon adds up.