Lag when calling BLS Transaction from within another

[Former Member]

Using MII 12.0.

In MII class, they told us a "best practice" was to check the "Reload Transaction after Execution" box in the configuration of a Transaction call within a BLS. The reasoning behind it was that should this not be checked, a previous result of that called BLS transaction would still be cached in memory and used instead of the newly assigned values from within your calling BLS.

Checking the "Reload transaction after Execution" box forces MII to reload that transaction when it is called.

In time analysis, what has been noticed is that there's a significant - up to 9 seconds - lag time when one BLS calls another BLS. On a time-sensitive operation, that is an eternity. That amount of overhead defeats any hope of using common code libraries.

Questions -

1. Is this a true "best practice", or is it one that adds unnecessary overhead to a BLS?

2. If the calling BLS executes 1 time - but is subject to be executed multiple times over a certain interval - is checking the Reload box of the BLS it is calling unnecessary?

3. Even if you pass new data each time you call that BLS, is it still going to use/return whatever data it has cached until the cache expires?

4. Is there another way to ensure that the called BLS uses the data you pass it (and returns the corresponding result set) without incurring the amount of overhead that we have noted?

Thanks

[Former Member · Accepted solution]

I never set the Reload transaction execution to true and the result that I get always the new result , not the cached result.

I am not sure if this really works. I am using MII 12.2 . In system property the parameter "transaction caching ist set to true"

For your time sensitive operation, you probaly need Asynchronous call rather than snyc. call.

hope this helps

sengkiang

[Former Member · Accepted solution]

Is that setting 12.2-specific?

We are currently using 12.0, and I'm haven't seen any property as you have described? If you could provide some sort of step-by-step navigation to where you are able to edit that property, it would be helpful.

Thanks!

[Former Member · Accepted solution]

Are you having problem that the value of your transaction always the the cached value?

I thought 12.0 is ramp up?

Anyhow in MII menu, under system Management -> System Properties, parameter Transaction Chacning

[Former Member · Accepted solution]

The version we're on is 12.0.6 Build 13, and moving to 12.1 (something I am not directly involved in). In this version, I'm not seeing the menu options you describe, so it's apparently in 12.1 or later.

The issue we are having if the "Reload transaction after execution" box is not selected is indeed caching of values.

For example -

BLS1 runs every 5 minutes

BLS2 is called from BLS1, and in this case, retrieves error log info from a table - a common module used by several BLS's.

BLS3 is also called from BLS1, and in this case, writes to an error log using information retrieved from BLS2 from within the execution of BLS1. BLS2 & BLS3's calls are in 2 separate sequences, one after the other.

If BLS2 & BLS3 DO NOT have the "Reload Transaction after execution" checked, each will run with whatever the cached data in memory is for them, even though inside BLS1 I am assigning values to the input of BLS1 to send to BLS2, and passing the returned data from BLS2 into BLS3. Unless it's checked, BLS2 & BLS3 would continue to be called, however, it would be with whatever data has been cached for them.

If that "Reload" switch is checked, it will reload each transaction & call it with whatever data is being passed.

This was mentioned in the MII class I was in also. This is a generalization, but the way they described it was being similar to how you might save a web page to your local PC, and that unless that page is refreshed & changed, that from that point on, every time you brought up your saved web page, it would always display the same values in it. They didn't go into great deal to explain the mechanics of it, but MII would only load it the first time it executed, and that unless you forced it (by checking the Reload switch), it would always execute using the same cached values no matter what you were passing.

[Former Member · Accepted solution]

Reload Transaction will be useful only when we are changing the BLS again and again because if we modify the BLS then only again it needs to be reloaded otherwise it is not required. But as a good practice we can clear samples of SQL Queries and Web Service action blocks time to time for better result.

[Former Member · Accepted solution]

Reload Transaction will be useful only when we are changing the BLS again and 
again because if we modify the BLS then only again it needs to be reloaded otherwise
it is not required. But as a good practice we can clear samples of SQL Queries and
Web Service action blocks time to time for better result.

This - useful only when we are changing the BLS again and again - makes sense. A BLS when in Development, I understand it making sense to do that in order to pick up BLS changes.

However, to simply pick up data changes, it doesn't make sense to me. In class, they told us to always do this, it was a best practice. The explanation of the "why" though, didn't ring true.

What is the definitive answer to "What happens when the "Reload Transaction After Execution" is selected or not selected?"

Is there a point where you have to have it checked to ensure you are receiving the correct data in the called BLS? What if you have a BLS that runs for 18msec that has to be capable of firing every 2-3 seconds?

I am just wanting to make sure that having it checked is truly a "Best Practice" and not a "habit" with unknown consequences.