OSMIS Technical Specification

Architecture Overview

2.5 Database Access

Reading and writing the model from, and to, the database is (obviously) a critical part of the OSMIS system. The Virtual Proxy pattern (see Section 2.3) takes care of hiding the complexity of database access from the user. It does this by having the proxy intercept getter methods as necessary. Factories/Helper methods are used to create and search for specific instances of variables, and a writing technique detailed below is used to commit objects to the database.


Assume an object contains another object within it, that has not been read from the database. The getXXX() (where XXX is the object name), will return a proxy for the object, and, when access is first attempted to the object, the call will be passed on to a helper class which will instantiate the object.


The helper class is invoked directly to create a new instance of an object. The created object will only be written to the database during a commit, as is done for standard writing.


Writing modified/batched objects to the database is done only after the user presses a save or commit button. Whenever a setter method is called, the object proxy for the modified object adds itself to an object called the WritingQueue. When a user decides to commit their changes, all objects in the WritingQueue are written to the database. Cancelling changes or moving to another module empties the WritingQueue without commiting the changes, though a dialog asking the user if he wants to commit the changes MUST be presented before the cancel takes place (clearly, if the user selects to commit the changes, they get written to the database as usual).


Since delete actions occur due to a button press, they are handled immediatly, without going through the WritingQueue.


Transactions provide support for the various ACID properties commons to DBMS systems. To prevent conflicts, optimistic transactions must be used. Two choices exist for transactions: system managed transactions, and programmer managed transactions.

To implement system managed transactions, a TransactionManager class must be defined. This class starts a transaction when an object is retrieved from the database, and ends the transaction when the object is no longer in use by the system. To remove the possibility of deadlocks, the TransactionManager must provide a timeout for transactions. It is possible, but difficult, to provide a connection based transaction mechanism using this approach. Instead, the current phase of the system will use programmer controlled transactions.

Every time an object is read from the system, it takes place within a transaction. Similarly, all writing from the writing queue takes place within a transaction. When reading or writing completes, the transaction ends. Using this scheme, the programmer is responsible for ensuring that no one has updated the fields in the database that are being written. For more information on this approach, see this document . If a conflict is detected, the user must be notified (with a dialog box), and the transaction must be rolled back. The view must be updated with the new data, which the user can then modify again, and attempt to update.

Note that standard techniques exist for implementing durable/long term optimistic transactions. These techniques are therefore not specified in this design document.

  << Previous Up
Next >>