MetaEdit+ automates all the functionality connected with supporting multiple users: it is perfectly possible to use it without knowing anything of the underlying principles. Users, however, are generally more curious than that, and an understanding of a few of the basics of the multi-user functionality will enable them to use MetaEdit+ more effectively, and give them a better sense of being in control.

There are three basic concepts that we will use in our explanations: session, transaction, and lock.

In MetaEdit+ a session is defined as the time from when a user logs in to the repository to when he logs out. As a rough guide, a session would normally last for a workday or some part of a day, and is generally the same as the time for which the user is running MetaEdit+. If a user wants, he can however exit MetaEdit+ without ending his session — more about this later. Each session is composed of one or more transactions.

As a term, transaction may be familiar to users of older style databases, where it basically represents an atomic unit of work. In MetaEdit+ there are some differences, but the basic understanding remains the same. As far as other users are concerned, your transaction is an atomic unit of work: until you end your transaction, they cannot see any of the work you have done during that transaction. You end a transaction either explicitly by committing it or by logging out.

Because your changes are not visible to other users until you commit them, transactions provide a measure of atomicity: people do not get to see your work until you are ready for them to see it. Transactions also provide a measure of a large-scale undo functionality: if you decide that you have taken a wrong turn in your design work during a transaction, you can abandon that transaction. All the changes you made during that transaction will be thrown away and not written to the repository, and you will start a new transaction in the same way as for commit.

In the everyday world, a person locks something if he wants to prevent others from manipulating it or removing it. A lock will prevent changes — your bike wheel disappearing, or your house being robbed — but in general will not prevent others seeing something (they can look at your bike, or peer in through your windows). The situation is in many ways similar in MetaEdit+, but here the main aim is to prevent two people making changes to the same information, rather than directly destructive acts. Thus, if another user has locked something, you can still look at it, but you cannot change it.

When you change a piece of information in MetaEdit+, it will first be locked, and only if that lock was successful will your change be allowed. A lock is successful if nobody else has held a lock on that piece of information in a transaction that overlaps with yours. Locks will also fail in cases where the user has no rights, e.g. to metamodel in this repository, or to model in this project.

The normal length for a transaction will depend largely on the way of working in an organization. If there is a need for very fast updates of information between different designers, transactions may last from half an hour to an hour. Where such rapid updating is not necessary, users can reduce the overhead of ending and starting transactions by using longer transactions. To help decide how best to use transactions we lay out some of the basics in the next few paragraphs.

At the start of each session, when a user logs in to the repository, a transaction is started for that user. The repository will remember its state at that instant, and throughout the transaction the repository will provide information as it was at the instant the transaction was started. Similarly, none of the changes the user makes to the information in the repository will be visible to other users until the user ends his transaction by committing it. At that point all his changes will be written to the repository, and will then be available to other users, but only read by them when they next start a transaction (remember that their current transactions will still be using the information available from the time they were started).

Thus for one user’s changes to be visible to another user, the first user must commit his transaction, and the second user must start a new transaction after that, either by ending his transaction (and thus starting a new transaction) or by logging in (if he is not already).

To summarize: the situation is as if you read from the repository only at the start of a transaction, and write to the repository only at the end of a transaction.

In MetaEdit+, locks are used differently depending on the kind of information and the current circumstances. Here we explain the types of locks and the different locking strategies in use in MetaEdit+.

There are two types of lock in MetaEdit+, transaction locks and session locks. A transaction lock is released (the information is unlocked) at the end of the current transaction, releasing it for other users. A session lock persists over into each new transaction, until the information is unlocked by some other action. For instance, graphs are session locked while they are open in an editor, and the session lock is only released when the user closes the editor.

The interval between your lock and your change varies with different kinds of information: most often it is negligible, but with some information, particularly graphs, locks are taken when you first open the graph, even though you may not change it immediately, or indeed at all.