Multi user SSAS writebacks may result to blocks on similar functions and new connections

Writeback consists of two distinct processes.  The first one is an update cube process that updates the current session with the changes.  Only the current user sees the changes and he can continue with updates and what/if analysis.  The second process is a commit so the changes get committed in the database and all users can see the results.

The challenge is when you have many users issuing writeback commits.  A writeback commit requires an SSAS database write lock. If it gets it, the other commit requests (eg. from other writebacks, cube process, alter roles etc) will have to wait.  Also, during this time, new connections cannot be made since a new connection requires a read lock of the database.