Gridarta Transaction System

The Gridarta editor (currently daimonin only, in future crossfire as well) has a transaction system. This document describes the current and future purposes of the transaction system.

History

Originally the transaction system was developed during reimplementing the maps as model view controller. Before I (Cher) started working on the editor, the code looked like being model view controller but it wasn't. The central point of model view controller is not naming classes model, view and control or whatever. The central point of model view controller is a message system and a view registry so each time the model changes, all registered views are notified and updated automatically. In Java, this is done via event listeners. This was missing.

When adding the event listeners to the map MVC, the system might have run into the problem that for instance when deleting a whole selected region, an event would be fired for every single deleted object, resulting in bulky slow behavior. I've added a transaction system that's first purpose was to group changes to the model so only the last change actually fires an event. The typical call sequence is: beginTransaction(), perform changes, endTransaction(). The event will be fired when endTransaction() is called.

The transaction system supports nesting. That means if a call sequence is: beginTransaction() ... beginTransaction() ... endTransaction() ... endTransaction(), only the last endTransaction() actually fires an event. In case an exception occurs, the transaction system also supports an endAllTransactions(), and for completeness I've added a getTransactionDepth() method.

Future / New Requirements

There are some requirements that could also be fulfilled using the transaction system.

• The transaction system could support undo / redo by creating a backup and storing that in the undo buffer each time the outermost transaction ends.
• To support undo/redo, transactions need names. The name of the outermost transaction determines the name of the undo / redo operation as visible to the user.
• An implementation of undo/redo via such a transaction system would also automatically provide undo/redo to scripts and plugins that change maps.
• If used for scripts and plugins, the transaction system should also provide rollback.