On Parallel Interaction 9.5.2

zrjz

Hi,

I am new to TM1. Was working on 9.5.1 so far. I have been recently going through the doc. of 9.5.2.
On Parallel Interaction, it says "Parallel Interaction addresses this issue by enabling the TM1 server to automatically manage multiple versions of only the modified data in a cube, allowing read and write operations to execute at essentially the same time"
I have a question here. What if two/more users write/edit the same value in a cell at the same time? Which value would it then take? Please correct me if my understanding is wrong here.
I have searched this forum before for the same question but i wasn't able to get hold of any solution.

Regards,
chand

onelovely

hyd_ladka wrote:What if two/more users write/edit the same value in a cell at the same time? Which value would it then take?

Simple answer: last update wins.  Why would you expect anything different?

To qualify this though it is the last update at the point in time the data is committed not necessarily when the update was commenced from the user point of view.  Say you had a large and long running data spread.  In the meantime another user could get in and make a small point update withing the region to which the spread was being applied and this change would be applied to the main model.  However when the spread finished and was committed then this would overwrite the interim values that had previously been committed by the other user.

On the whole this seems sensible to me. I don't see how they could have designed it any differently.

gdisoft

Okay.
Got it. Thanks!
Now, will a user be able to know or identify if someone else is trying to change/modify any value on which he is working?
I don't think so. am i right?
Thanks again!

bxmsw

hyd_ladka wrote:Now, will a user be able to know or identify if someone else is trying to change/modify any value on which he is working?
I don't think so. am i right?

You are indeed right. However, you can always design the model so that it prevents this or at least reduces the chance of this happening by applying any combination of the following solutions:
- workflow control,
- security,
- the Reserve functionality,
- multiple input cubes,
- etc.

hsszjw

lotsaram wrote:On the whole this seems sensible to me. I don't see how they could have designed it any differently.

The solution, difficult as it might be to implement, is how Bugzilla handles it.  If your write includes a cell which has changed since you last read it, you get a warning.  You can still proceed to overwrite the other user's commit, but at least you get an FYI.

Matt