Is it possible to run two partial reloads at the same time?
I have an app with a button that calls a partial reload.
If two users press this button at the same time, what happens? Currently, what I'm seeing is that one user gets the correct details back, but the other does not get new data. But I'm not totally sure why this happens. Is it because the dashboard simply didn't reload (as it was already in progress for the first user) or could it be something else?
It's really hard to debug anything to do with partial loads, but more so when you're looking at concurrency.
I guess really the most important question I have is, if user A starts the partial reload, and while it's running, user B changes a variable in the frontend, will that effect the currently running reload? I know that the reverse is true, that variables that user A changes with the partial reload in the script will take effect on B's dashboard (once the script is finished) but it's kind of unclear when frontend variable changes become 'global' and if that could even effect a reload started by another user.
I am currently working with what seems like a similar use case where multiple users could be using the same app to extract data based on variables set in the front end. If this were to occur I would assume the data extract would be screwed (possibly).
I've tried locking down or hiding the variable inputs whilst a reload is taking place, this works fine in User A's session but is not reflected in User B's session.
We had 'some' luck, and then the project was canned, so the proof of concept didn't fully explore all possibilities, so, take this with a pinch of salt. What we did get working though, was a fairly complex system, whereby we would save all extracts to a QVD, along with the OSUser() and a timestamp, and then in the frontend had set analysis to only show data matching your OSUsername and with the latest timestamp. (I think we just used a flag on the QVD for 'latest per user').
You can only append to this QVD (which would get overwritten on a full reload every night with the refresh of the rest of the dashboard) because otherwise you could overwrite someone 'elses' results, hence the need to keep your old useless results but mark which is newest. You could probably do something to remove the old while you append the new, or perhaps even better, have a unique QVD for each user, but this got a little bit messy with our implementation.
By doing it this way it ensured that no one would ever see anyone else's results. We had really mixed results though, with simultaneous reloads. Just massively inconsistent to the point I couldn't really say one way or another what was going on. For a long time at first, it just worked, and it all seemed great. But then one day it didn't (without a new code release) and somehow you'd get a weird situation where one persons didn't 'look' like it had reloaded until you did 'something' else. (I.e. if you ran the partial load again, your old results would be there, or sometimes just making selections for a bit). So, there's definitely some other issues to solve.
However. A bigger problem was that, all variables in the backend will apply for all users. So, all the variables you're using to make various API calls / hold query stings etc. To get around this, we'd create dynamic variables using the OSUser(). You can't just call this in the backend (I think it ends up getting the system account) so you have to set it all up in the frontend, naming your variables horrific things like =$('OSuser()')&'_Query_String'. Sorry, I'm recalling the syntax from memory there so you might need more or fewer quotes or whatever, but you get the idea. You end up with a variable that's called like, AJPeaBody_Query_String. Then you have to set a variable to hold the OSUser() as well, so that in the backend you can go:
And have it evaluate to SELECT $('AJPeaBody_Query_String')
(Which actually evaluates again to SELECT 'chips from foodtable where cookingstyle like(*fried*)' ) or whatever. Again, sorry about syntax. I'm just guessing. Feels like you have to trial and error it every single time.
Oh, one other issue we ran into that I don't think there's a good solution for: You need two buttons. You need one button that sets everything up, and one button that ONLY runs the partial reload. It took a while to work this out, but essentially the buttons in Qlik are multithreaded? or something? Basically, they don't actually always run the tasks in the order you put them. So if one of the tasks is 'run partial load', that might happen before all the others, and you get a nondescript error message. By having the buttons separate (with maybe a conditional hide / show on the reload one) you ensure that everything is set up before running the reload. It feels quite clunky, but was the only way we could guarantee it would work.
