Novel Transaction Modes

Many of Objectivity's early customers were implementing workgroup applications. This led to the provision of a crude form of persistent transaction. "Long" transactions could obtain a lock on an object, container or database and have that lock held past the transaction boundary. The lock was tied to a username rather than a process or thread identifier. A subsequent process, perhaps days later, could carry on using the data and eventually release the lock. It's not a frequently used feature, but its still there if you look hard.

One frequent request was for a mechanism to support GUI "undo" operations. The easiest way to do that is to not commit the transaction at the end of a screen interaction. If the next user operation is "Undo" you simply rollback the transaction. If it's anything else you commit the transaction before starting a new one. There is a minor exposure, but users of that kind of application are used to having to explicitly save their data, so they're generally impressed when they find that all but their latest operation has been safely committed to disk, unlike most file-based applications.

An optional mode, that we may add later, would make it possible to handle nested transactions. An inner block can be committed but it may eventually be committed or rolled back by the owning block. The mechanism is generically labelled "Nested Transaction" and it can be very useful in some kinds of application. You can achieve something similar for now by careful use of sessions, thread pools and their associated cache.

The CAD/CAM people were always particularly demanding. Imagine a design application that has an engine block displayed on the screen. The user brings up a new window to create finite element mesh and another one to start generating the numerical control program that will cut the metal. However, the analysis finds a weakness, so the numerical control program generator has to be rolled back, changes made, then the analysis and generation can start again. That's not a nice neat ACID transaction, but it's similar to what might happen if you're working with a spreadsheet and generating multiple charts. You might save some and discard others, having saved the original data one or more times.

So, we made it possible to commit an individual container in the middle of a transaction, but not release the locks.That feature had to be used with great caution, because committing the finite element mess (in the above example) without also committing the design, would cause problems later. This kernel functionality might be best used for something like security audit trails, which can't be rolled back no matter what the user does. In any case, you won't find this feature mentioned anywhere in our documentation any more. It's something our engineers utilize for customers on an as needed basis.

Design applications may also need to share the contents of the cache between threads or processes, perhaps belonging to different users. That mechanism, known as a cooperating transaction, involves assigning a label to a nested transaction and allowing other users to read the contents when the owning transaction is quiescent. It may also be possible to pass an update token around amongst the viewers. This requires the use of in-process shared memory, but we might also implement it with a transient shared cache in the Advanced Multithreaded Server.

You can turn locking off altogether, but that also turns off recovery, so that's something I'd only recommend during development. A more useful mode involves getting a catalog lock, e.g. to declare a whole database as read-only. That can dramatically reduce the lock traffic for a reference database that is being used by a large number of clients.