Sunday, January 03, 2010

Matrex 2.0: project integrity in a multi-user system

Now it is a long time the alpha version of Matrex 2.0 was published, but a beta is still not available. The reason is that the task to make the core objects (project, matrix, function...) thread safe is complex.
Until now Matrex was a single-user system. That does not guarantee against concurrency problems, but makes certainly things easier than on a multi-user system, like Matrex 2.0. In Matrex 2.0 a function or chart or presentation can potentially be changed by multiple users in the same time, which can lead to unpredictable results.
To avoid this, the work I'm doing now is to make the project object not only a repository of its items (matrices, functions...) but to give it the responsibility of its own integrity, and to this, the complete responsibility of adding, updating and deleting items.

In Matrex 2.0 the chart editor, for example, is not able to update a chart object directly. It tells the project how to change the chart object, and the project changes it, after it checked that the change is possible and does not break its own integrity: charts are dependent by matrices and it could be possible that the change involves adding a matrix to it that during the chart editing gets deleted by a different user; in this case the project rejects the update, the chart does not get change and the editor gets an error.
The project's methods are guarded, so that it is impossible to do incompatible changes in the same time. For example it is not possible to delete a matrix in the same time a chart is updated.

In other words the project in Matrex 2.0 looks a lot like an SQL server with transactions. The SQL server makes sure two SQL updates cannot take place on the same rows of a table in the same time and an SQL update (or a group of them) can be integrally rejected (rollback) if something goes wrong, leaving the database as it was.

A side effect of these changes is that, since everything is done through the project, the items become more or less read-only for the editors and the rest of the GUI, simplifying the system.

In terms of performance these changes should be in-influent. What is important for the system performance are not the items editing, but the matrices calculations that derive from it, which are much more complex and CPU consuming.

I'm now in the middle of the work of changing project, items, editors to make them work in this way. As soon as I am finished I will publish a beta.