Temporary views surviving their TI process

[PavoGa]

Ran into this last week.

A sub-process creates a temporary view using a non-temporary subset from another sub-process. That view is surviving its process and the master process, which tries to delete the subset in its EPILOG, is aborted because the subset it tries to destroy is reported as existing in a view. Tested in the master process and found that the temporary view does still exist after the sub-process completes. Also tried SLEEP to see if was simply a matter of the system not having enough time to register the destruction of the temporary view and that did not alleviate the problem. The subprocesses are called using EXECUTEPROCESS.

What is rich is the non-temporary subset is destroyed, although that is most likely because of the aborted process.

Easy enough to work around or avoid, but thought it interesting behavior and I wonder should that be considered a bug? Or is it expected because of everything being within the master process transaction?

[Bakkone]

Any chance you could share some code?

[PavoGa]

Any chance you could share some code?

Not sure there is really any code to share. In this case, I just use the ViewDestroy in the offending sub-process EPILOG and that took care of it. This instance was unusual as I normally build all my subsets as temporary within the process they are to be used with a subset name that is randomized and unique to that process.

[lotsaram]

A sub-process creates a temporary view using a non-temporary subset from another sub-process.

Are you sure? As in are you sure, you're sure? In my experience trying to assign a temp subset to a non-temp view (or vice versa) will result in an error and the process aborting. So if you are managing to assign a temp subset to a non-temp view, then how?

[PavoGa]

A sub-process creates a temporary view using a non-temporary subset from another sub-process.

Are you sure? As in are you sure, you're sure? In my experience trying to assign a temp subset to a non-temp view (or vice versa) will result in an error and the process aborting. So if you are managing to assign a temp subset to a non-temp view, then how?

I know what you are talking about as I've had the same issue, but this works fine. It is a temporary view using a non-temporary or permanent subset and we do it quite a bit with permanent subsets that return default sets/members by client. That could be causing this particular problem and I did not test if a temporary view survives its process if only built with temporary subsets.

And before you ask, yes, using the third argument in the ViewCreate...

Code: Select all

ViewCreate(cubName, vwName, 1);

SubsetAssign(cubName, vwName, dimName, subPerm);

[lotsaram]

I think you might actualy be exploiting a bug Ty. AFAIK assigning a permanent subset to a temp view isn't supposed to work and you may find that on next upgrade all processes using this "feature" break.

I would try and confirm with IBM support if this is actually supposed to work.

[qml]

I think you might actualy be exploiting a bug Ty. AFAIK assigning a permanent subset to a temp view isn't supposed to work and you may find that on next upgrade all processes using this "feature" break.

Not entirely sure what the intended behaviour is, but a few versions ago we were using temporary views with persistent subsets and it generally worked, but there was the occasional bug where the process would hang during the commit phase. In the server log it looked like it had finished, but it was still hanging there, presumably trying to clear the temporary objects and failing. The only way to terminate such hung process was to restart the service. For that reason we have moved away from mixing temporary and persistent objects, but we have also been told since then by IBM that the defect is now fixed, so perhaps if mixing object types is still possible after these tweaks then we can conclude it's how it's expected to work?

For clarity - using temporary subsets in persistent views shouldn't be possible and I don't think it is.

[tomok]

We've got a handful of processes, created by a consultant many years ago, that use permanent subsets in several of the dimensions in the source view. When IBM came out with the extra parameter for setting views and subsets as temporary I added that parameter to all the views and subsets (excluding those that were assigned to permanent subsets) and we haven't had any issues. No errors and all the temporary objects get deleted after the process completes. I did this under 10.2.2 and it survived our migration to the IBM Cloud.

[PavoGa]

I think you might actualy be exploiting a bug Ty. AFAIK assigning a permanent subset to a temp view isn't supposed to work and you may find that on next upgrade all processes using this "feature" break.

I would try and confirm with IBM support if this is actually supposed to work.

We will find out soon enough. About to upgrade to 2.0.08. Currently on 2.0.05. However, your suggestion is noted and will see about querying IBM.

Tom, we are not having problems deleting the temporary objects. This is a peculiar example where we are creating a subset once and using it in sub-processes to construct their temporary views. Tested for it in the Master Process with ViewExists and the temporary views are most definitely surviving the end of the sub-processes. It may be because the view contains a persistent subset. I have not tested it, but do wonder if it is because the view is contained within the transaction of the Master process. When I get a chance, I want to test it.

[ykud]

Somehow it didn't make it to the front pages of 'What's new in PA XXX', but it's there in the documentation:
https://www.ibm.com/support/knowledgece ... reate.html

TM1® Server version 11.2.0 and earlier, temporary views were visible and usable only by the process that created it and any of its child processes. Temporary views were not visible to the ancestor and sibling processes. You could create same-named views in sibling child processes with the same parent process.

For TM1 Server version 11.3.0 and later, these temporary views are visible to the ancestor and sibling processes. If a parent TurboIntegrator process A invokes two child TurboIntegrator processes A1 and A2, and the child TurboIntegrator process A1 creates a temporary view S, the temporary view S exists for the duration of the parent TurboIntegrator process A. You cannot create a temporary view with the same name S in the sibling TurboIntegrator process A2 since the view is visible and usable by siblings A1 and A2.

[PavoGa]

And yet another reminder why reading release notes and such is important.