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.Reading
Assume an object contains another object within it, that has not been
read from the database. The
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
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
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
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.