Re: For the AdaOS folks

[Nick Roberts <nick.roberts@acm.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> The other means would be by mapping everything to L/DSM. The problem is
> how to achieve different views on the same storage.

I think one would build layers on top of the database to achieve this.

For example, you might have a table for text files with the fields "Name",
"Encoding", and "Data", of types Char Varying, Enumeration, and BLOB,
respectively. The Encoding field would say what the charcater encoding of
the data was, so that the binary data in the Data field characters can be
interpreted as characters. One might then have a class (of system objects)
"Text_File" which has a method to read a sequence of characters; this method
would invisibly use the Encoding field to select the correct algorithm to
interpret the Data field.

> As I mentioned in discussion with Warren, I would like to have something
> like Ada protected object with protection enforced by memory mapping.

What I envisage is a locking (and transaction) protocol based on the model
described by the SQL-92 standard. This would achieve the same essential
objectives as an Ada protected object, but with the added functionality of
transaction rollback, and more implementational flexibility. I'm not wedded
to the use of the SQL-92 standard, however.

One possibility is a translator that would generate Ada code from a
specification written in a language designed to conveniently describe how
database tables (or views) are to accessed in a program. The generator would
generate both an Ada package specification and its corresponding body. The
spec could contain an interface (to a database table) that would be similar
to the interface of a protected object. The body would contain the nasty
messing about necessary to access the database.

> Then there is of course the issue of reset/restart/upgrade. System objects
> have to be organized in a way which would allow restart failed system
> parts. One would never be able to restart the whole [distributed] system
> once it runs.

This is why a comprehensively transactional system would be so important. 

The system would be designed so that transactions were guaranteed to be
effectively atomic, even for changes spread across the network; in
particular, rolling back would be guaranteed atomic as well as committal.

This way, any failure anywhere in the network would cause the affected
transactions to be rolled back -- and this would be guaranteed to succeed in
getting the system to a stable (consistent) state -- and then the remainder
of the network could proceed correctly from there, with software components
restarted as necessary.

-- 
Nick Roberts