QlikView: Server-side exports and dynamic updates causing app freezing or blocks users from entering accesspoint

When using server-side exports and dynamic updates with larger apps, there are a couple of unexpected behaviors that have been encountered. For example, if two different users perform a dynamic update on the same app at the same time, the application freezes or user's session is lost. If one user is performing a dynamic update with or without and export, and another user tries to enter the accesspoint to open the same QVW, they will be stuck on a white loading page and will eventually see the error, "Failed to open document, for unknown reasons." Smaller apps do not seem to have the same issue.

Environment:
QlikView 11.20 to 12.40

 

The error "Failed to open document, for unknown reasons" when entering the accesspoint to open the same QVW that is already performing a dynamic update by another user is considered to be the expected and correct behavior. After the DU is finished, the user can open the already updated document normally.

As for the issue regarding two or more users running dynamic updates at the same time, this is caused by a product defect. The cause of this from what can be understood from R&D for what is happening under the hood is that dynamic updates are not locking the file, instead, when a call is made to the DynamicUpdateCommand, there is a call to InterlockedCompareExchange ( https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange ) with pDoc->DynamicUpdateBusy set as a value. If this is 0, that is, no DU operations in progress, then it sets it to 1 and any other users that might want to perform any DU will be reschedule to call DynamicUpdateCommand again. As long as the DU operation is taking place, requests will be infinitely rescheduled, which may cause lost sessions. If for any reason the value pDoc->DynamicUpdateBusy remains set to 1 after the DU operation is finished, which should not happen, then no other DU operations will be possible for that document as any request will be rescheduled indefinitely till the value is reset, making the app appear to be frozen.

Larger apps tend to experience these issues more easily because the issue is time dependent, and larger applications allow for a long enough delay for the before mentioned use cases to trigger the unexpected behavior. But size is not so much the factor behind this. Dynamic updates naturally use a lot of resources, which varies according the the complexity of the data model. For example, if the field in question is associated to many other tables, and if the topology is very complex, then it might take some time to perform a dynamic update which increases the changes for these issues to be triggered. In other use cases where a server-side export is being used in conjunction with dynamic updates, the delay might be coming from the time it takes to save to a QVD with both methods being ran in the same script together, which is not recommended.

R&D has fixed the issue regarding freezing and or lost sessions when there are two or more users running dynamic updates at the same time. That fixed is targeted for QlikView 12.50, which is scheduled for release sometime in the beginning of 2020, possibly February.

If dynamic updates or other functions are failing due to hanging/broken sessions not terminating correctly, then this is a separate issue. Updates regarding the progress of that issue can be checked by referencing QV-19259 when contacting Support.

Note: It also may be beneficial to review this article What are the Pros and Cons for use of Dynamic Update when considering to use dynamic updates.