Adding persistence to the Oberon-System

Knasmueller, Markus

doi:10.1007/3-540-62599-2_33

Cited by 4 publications

(3 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since the fields may contain platform-specific representations of data types, information about their types is required in order to perform the correct conversion operations. As has been noted in various places [8,17], it would be advantageous for these purposes if a record's type tag were extended to hold this information.…”

Section: Message Linearizationmentioning

confidence: 98%

A messaging architecture for distributed objects in Oberon

Scherer

1997

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract.A distributed messaging architecture built on top of current Oberon System 3 implementations is designed and implemented. It is aimed at supporting a CORBA-inspired object request broker architecture for distributed objects. The emphasis is on compatibility with System 3 messaging without requiring modifications of existing systems. Some Oberon-specific issues are identified which require workarounds in the solution, and proposals are also made for improved distributed messaging support in future systems. The implemented solution is presented in detail and uses a precompiler for message-specific communications procedure generation without restricting runtime flexibility for message types.

show abstract

Section: Message Linearizationmentioning

confidence: 98%

A messaging architecture for distributed objects in Oberon

Scherer

1997

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…This is different to our model, where a chain of persistent references from a persistent root cannot be broken by an object explicitly forced to always be transient, which implies the risk of dangling persistent references in Persistent Modula-3. [21] shows the integration of transitive persistence into classical non-concurrent Oberon but does not support any transactional features. Optional custom internalization and externalization functions are proposed by [21], to ignore certain references for persistence reachability, which is solved in our work using transient or weak references.…”

Section: Persistent Programming Languagesmentioning

confidence: 98%

“…[21] shows the integration of transitive persistence into classical non-concurrent Oberon but does not support any transactional features. Optional custom internalization and externalization functions are proposed by [21], to ignore certain references for persistence reachability, which is solved in our work using transient or weak references. PJama [5,6] is a system providing persistence for Java, also based on reachability from a persistent root.…”

Section: Persistent Programming Languagesmentioning

confidence: 98%

Persistent Oberon: A Programming Language with Integrated Persistence

Bläser

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. This paper presents the programming language Persistent Oberon, which offers persistence as a naturally inbuilt concept. Program data is automatically kept durable and stored in non-volatile memory, without the programmer having to write explicit code for the interactions with an external database system. In the case of a system interruption or failure, the program can directly continue from its latest consistent state. In contrast to other existent persistent programming languages, this language does not need any artificial programming interfaces or commands to use persistence. The programming language is completely implemented and offers a high scalability and performance.

show abstract

Managing schema evolution in a container‐based persistent system

Perez-Schofield

Roselló

Cooper³

et al. 2002

Softw Pract Exp

View full text Add to dashboard Cite

Managing schema evolution is a problem every persistent system has to cope with to be useful in practice. Schema evolution consists basically of supporting class modification and dealing with data objects created and stored under the old class definitions. Several proposals have been made to handle this problem in systems that follow a full orthogonally persistent approach, but, until now, there has not been any proposal to support it in container‐based persistent systems. In this paper we describe a schema evolution management system designed for Barbados. Barbados is a complete programming environment which is based on an architecture of containers to provide persistent storage. Barbados does not provide full orthogonal persistence, but, as will be described in this paper, its architecture has several other advantages. Among them is the fact that this model is especially suitable for solving the schema evolution problem. Copyright © 2002 John Wiley & Sons, Ltd.

show abstract

Adding persistence to the Oberon-System

Cited by 4 publications

References 6 publications

A messaging architecture for distributed objects in Oberon

A messaging architecture for distributed objects in Oberon

Persistent Oberon: A Programming Language with Integrated Persistence

Managing schema evolution in a container‐based persistent system

Contact Info

Product

Resources

About