Re: For the AdaOS folks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 5 Jan 2005 18:33:53 +0000, Nick Roberts wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> 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.

OK. One note though. In fact Ada's entry points have some equivalent of
rollbacks. When an entry call is aborted it is basically same as rolling
back the transaction. Especially if internally the call is routed through
many queues. Of course all internal "requeue"s should be "with abort" and
the implementation should take care about internal state of the objects
involved.

> 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.

Much work in the linker/loader field, also.

>> 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.

Agree.

Also there must be a deeper hierarchy of nested objects and scopes where
system exceptions could propagate. Presently it is basically the system and
applications. When the system cannot handle an exception propagated out of
some application it crashes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de