Locking Issues

BrianL
MVP
Posts: 264
Joined: Mon Nov 03, 2014 8:23 pm
OLAP Product: TM1
Version: 9.5.2 10.1 10.2 PA2
Excel Version: 2016

Re: Locking Issues

Post by BrianL »

Duncan P wrote:...the same level of functionality (and editing support) as DOS batch script circa 1990.
I agree completely with your comparison. I was just stating my opinion that the java extensions for TI are more of a hacked in workaround to those limitations than an actual well designed solution.
Duncan P
MVP
Posts: 600
Joined: Wed Aug 17, 2011 1:19 pm
OLAP Product: TM1
Version: 9.5.2 10.1 10.2
Excel Version: 2003 2007
Location: York, UK

Re: Locking Issues

Post by Duncan P »

I can't argue with that.
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Locking Issues

Post by paulsimon »

Hi Brian

I think you were talking about the ability to call Java from TI. I was more interesting in the ability to call TI from Java.

As an example I frequently write TI where I am basically doing the same thing, eg check if an element exists in a dimension.If not define an error message. Output that to a cube holding messages for the user, and then do an ItemReject. I sort of parameterise this by using vDim and vElem within the code, and then just set vDim and vElem to the appropriate values at the start. Then I just have to copy the checking code and change the assignment to vDim and vElem for each existence check that I want to do. However, I am a long term programmer and copying code just seems wrong. I would rather be calling a subroutine (or method in Java terms). I could do that in Java, but the calling overhead in TI is too great and there is no easy way to return data, except by global variables or a shared cube. The global variable option would generally not be regarded as good programming.

Hi Steve

As a Use Case for the Commit statement, I frequently use master processes to call other processes. That means that the locks stay on the whole time. It is often convenient to update a dimension and store attributes. We are now being told to do that in two separate processes because otherwise locks from the dimension update are retained during the attribute update. However, if we had the ability to issue a commit at the start of the Data Tab to release locks then we would not have to split processes into two. This is just an example, I have some rather more sophisticated dimension update routines. Another example is the need to write out a file when doing a cube to cube transfer to avoid locks. I know that there are workarounds, but the aim in my view should be to make TM1 something that a technically competent accountant can use, and not require someone with an IT degree.

Regards

Paul Simon
User avatar
tiagoblauth79
Posts: 25
Joined: Fri Aug 26, 2016 1:42 pm
OLAP Product: Cognos BI and TM1
Version: 10.2.2
Excel Version: 10
Contact:

Re: Locking Issues

Post by tiagoblauth79 »

Sorry for the 2 years late reply, but I did test something interesting today in TM1 10.2 and I want to share.
- TI process with no source, dimension item insert and/or delete in Prolog: no cube lock;
- TI process with a source, view create, subset create, data values changes: no cube lock;
- TI process with a source, dimension item insert and/or delete in metadata: cube lock until the process or the full chore ends.

I read other comments saying if you split the process in more than one process (one for metadata updates, other for data updates) the problem is solved (as in general the metadata part is smallest), but it needs to be triggered in separated. I did solve this last piece by using tm1runti: first, you do all metadata updates you need; and later you run a tm1runti to trigger a separated TI process with the data updates you need. This way you can trigger one single TI process to update both dimensions and data.

I hope this helps someone with the same issue I had.
Post Reply