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.

Matrex 2.0 is not just a specification anymore

After more than two months of work I was able in these days to let Matrex open a project in a Matrex server.
This is how it works:

In Matrex click on the menu File->Connect. The following dialog appears:


In this case the server is on my PC, the same one in which I run Matrex, so I write localhost as server address.
Clicking on Names, the Matrex Server combo box is populated with the list of available servers in the PC with the given address.
In my case there is only one server, default.
I press OK. The login dialog appears:


Guest is the default user, with password guest. It is the user that is available by default in the server, if it has not been configured.
I write user id and password and press OK.
The remote machine tab for the localhost server appears, beside the local machine:


In the machine menu I click on Open Project. The Open Remote Project dialog appears:


Differently from the local projects there is only the possibility to choose in a list of projects. In facts on the server side the projects are all under the same directory, projects.
I select the example project popcolorado and the project opens:



By now I checked that it is possible to open matrix and functions viewers and editors.
In the next days I will check all the project's functionalities.
As usual, the sources for the last version of Matrex are under the Matrex subversion repository.

As soon as I have a version that is tested enough, I'll publish it as a pre-alpha.

Client/Server: technical view

As told in the previous article, I'm changing Matrex from a pure standalone desktop application to an application that allows to work standalone or in a client/server architecture.
To support the client/server architecture I use the RMI protocol.

This means that the calculation engine, the one that calculates the functions and therefore generates the content of matrices, presentations, charts, will be both in the desktop application and in the server.
For this reason, the GUI has to use in the same way the objects involved in the calculation (projects, matrices, functions...) , whether they are on the client side or on the server side.
To do this, the original calculation objects (projects, matrices functions,...) are wrapped in two different new categories of objects: Local (client) and Server:



Both the wrappers, share the same remote interface (which extends the RMI's Remote interface).

The reasons I use wrappers instead of the original objectts is because all the methods of a RMI business object must throw the RemoteException exception.
RemoteException is needed to understand when the server is down or there are problems of connection, so I would never do without it.
On the other side, it becomes annoying to catch it every time some code calls a method of a business object, so I want to do it only when it is strictly needed.
So I use the wrappers only in the GUI, where it is needed. Instead the calculation engine uses the original objects.

Now, why Local and Server wrappers? Why not use only Server wrappers, both on the server and on the client side?
There are several reasons:

• Server machines and projects have slight different interfaces when they are on the client and on the server side, mainly because projects on the server side can only be saved in a specific directory, projects on the client side can be saved in any directory of the disk.
• The server wrappers extends the UnicastRemoteObject, local wrappers don't. I don't really understand completely how the Java compiler and RMI compiler handle these objects, so I cannot be sure that they don't have some effects on the application's performance. If these performance effects are needed with the server business objects, I don't want them on the local objects.

And why I did not use the original classes instead of the Local wrappers? Because I needed a special wrapper for the Matrix class when it is used in the GUI, and only when used in the GUI, called SafeMatrix, which makes the Matrix methods thread safe.
But this means that all the other calculation classes need to have parameters of type SafeMatrix when called by the GUI, and instead use parameters of type Matrix when called by the calculation engine. And this means that I need special wrappers that use SafeMatrex parameters, the Local wrappers.


So, now I'm working on it. I will take some time, because in the GUI all the references to the original objects must be changed to the new remote interfaces.
Which means:

• remote exceptions to handle.
• utility functions to convert the original classes to the wrappers.
  
• some code duplication.
• many wrappers to write, expecially for the charts, for which there is one class for each chart type.

Also, I expect to reduce the number of methods in the calculation classes to reduce the number of remote calls.

When I have something that more or less works I'll publish it as an alpha version.

Working on client/server

I started to work on the client/server version of Matrex, the 2.0.

This version, as explained in the specification, will give the possibility to use Matrex in two ways:

• standalone, as today
  
• connected to one or more Matrex servers.

When Matrex opens a project in a server, all calculations for that project are done in the server: Matrex acts only as a graphical interface.
One would open a project in a server:

• to use the CPU of the PC running the server instead of the one of his own PC.
• to share the project with other people. In fact two or more Matrex clients can work on the same project in the same server in the same time, without problems.
  

Matrex has been written from the start to become one day a client/server system, so the GUI will not change so much: not much more than a new menu to connect to a server (I will publish some pictures as soon as I have a stable version).

The protocol used is RMI, but I will keep the possibility to use different protocols in the future. It could be nice to have a version (based on REST?) that can work on the internet through the firewalls.

Matrex 1.3.5 almost ready.

Last tests for the version 1.3.5 of Matrex, which will be probably released in the last half of May.
The changes are many, but surely the most important are:

• Flexible configuration files, which allow Matrex to be installed in packages or setup files.
  
• The project diagram

together with many bug fixes.

Compatibility with Java5 : Matrex 1.3.01

I published a new release of Matrex, 1.3.01, to cope with the fact that Matrex 1.3 was able to run with Java6, but not with Java5.
The problem was a call to the String.isEmpty() method, which is only available from Java6.
In 1.3.01 this call has been replaced and this version has been tested with Java5.

Thanks to Braxton who found the problem.

Matrex 1.3. Development finished.

Matrex 1.3 coding has been finished.
I'm now testing it and updating the documentation.
Hopefully I'll release it at the end of september.

Status

Today I finally released matrexjruby 1.0.2 (you can find it in the Matrex download page). It took some time to do the final test because of the frenetical work on Matrex 1.2.
I'm now working on the last pieces of code of Matrex 1.2, since ISQL has now been tested and I consider it finished:

• the code that allows to add a function from the matrix tree using as first matrix parameter the selected matrix.
• the code that allows to create an item from the item selection dialog box.

Once these are finished, I need to do some more test and update the documentation. I hope 1.2 will be released in january.