object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the right way to solve the problem is to allow objects of classes defined in the same module to have privileged access to each other's representations; we show how to do this for inner classes. This approach allows programmers to express constructs like iterators and yet supports local reasoning about the correctness of the classes, because a class and its inner classes together can be reasoned about as a module. The paper also sketches how we use our variant of ownership types to enable e#cient software upgrades in persistent object stores.

We show how structured data stored in files can benefit from standard database technology and in particular be queried and updated using database languages. We introduce the notion of structuring schema which consists of a grammar annotated with database programs and of a database schema. We study the translation from structured strings to databases, and the converse. We adapt optimization techniques from relational databases to our context. 1 Introduction Database systems are concerned with structured data. Unfortunately, data is often stored in an unstructured manner (e.g., in files) even when it does have a strong internal structure (e.g., electronic documents or programs) . In this paper, we consider how data stored as strings can benefit from standard database technology and in particular be queried and updated using database languages. In actual systems, data is often stored as string for obvious historical reasons. The problem that we are considering is thus very general. Tools...

The goal of this work is to integrate in a general framework the different query optimization techniques that have been proposed in the object-oriented context. As a first step, we focus essentially on the logical aspect of query optimization. In this paper, we propose a formalism (i) that unifies different rewriting formalisms, (ii) that allows easy and exhaustive factorization of duplicated subqueries, and (iii) that supports heuristics in order to reduce the optimization rewriting phase. 1 Introduction Many declarative query languages for object-oriented database management systems have been proposed in the last few years (e.g. [4, 5, 9]). Currently, a very serious concern is their optimization. Interesting techniques have been imported from other environments or developed for this context. However, although complementary, these techniques are often supported by distinct formalisms. The implementation of a query optimizer is thus still an awkward and delicate operation. Clearly, i...

Making software reliable is one of the most important technological challenges facing our society today. This thesis presents a new type system that addresses this problem by statically preventing several important classes of programming errors. If a program type checks, we guarantee at compile time that the program does not contain any of those errors. We designed our type system in the context of a Java-like object-oriented language; we call the resulting system SafeJava. The SafeJava type system offers significant software engineering benefits. Specifically, it provides a statically enforceable way of specifying object encapsulation and enables local reasoning about program correctness; it combines effects clauses with encapsulation to enable modular checking of methods in the presence of subtyping; it statically prevents data races and deadlocks in multithreaded programs, which are known to be some of the most difficult programming errors to detect, reproduce, and

Persistent object stores require a way to automatically upgrade persistent objects, to change their code and storage representation. Automatic upgrades are a challenge for such systems. Upgrades must be performed in a way that is efficient both in space and time, and that does not stop application access to the store. In addition, however, the approach must be modular: it must allow programmers to reason locally about the correctness of their upgrades similar to the way they would reason about regular code. This paper provides solutions to both problems. The paper first defines upgrade...

THOR is a persistent object store that provides a powerful programming model. THOR ensures that persistent objects are accessed only by calling their methods and it supports atomic transactions. The result is a system that allows applications to share objects safely across both space and time. The paper

In a distributed storage system, client caches managed on the basis of small granularity objects can provide better memory utilization then page-based caches. However, object servers, unlike page servers, must perform additional disk reads. These installation reads are required to install modified objects onto their corresponding disk pages. The opportunistic log is a new technique that significantly reduces the cost of installation reads. It defers the installation reads, removing them from the modification commit path, and manages a large pool of pending installation reads that can be scheduled efficiently. Using

Abstract | This paper tells the story of OQL, the standard query language of the Object Database Management Group (ODMG) [30]. The story starts in 1988, at INRIA in the Alta r Group y. The objective of that group was to develop an object-oriented database system [41]. This objective was reached: in September 1991 the O2 database system started its commercial career as the main product of a company called O2Technology [6]. As opposed to its competitors, O2 featured a full- edged query language named O2SQL [22]. The story goes on with the creation of the ODMG in 1991 and the adoption of O2SQL as the standard object query language under its new and nal name: OQL. During the following years, OQL went through some modi cations, the most important ofwhich resulted in OQL 1.2 that o ers some level of compliance with SQL92. On top of providing the expressive power of the SQL92 query language [54], OQL allows objects to be queried. This is a claim also supported by the upcoming SQL3. However, due to its adequacy to the object oriented type system and its functional nature, OQL is much simpler to learn, use and implement. A goal of this paper is to demonstrate this. This paper tells about the mistakes and pertinent choices we made while designing and implementing OQL. I hope it also conveys the great pleasure I had to be part of this adventure. Key words: Object-oriented database, query language 1.

This paper discusses issues raised by providing disconnected operation in the Thor object-oriented database system. Disconnected operation in such a system poses new challenges because of the small size of objects, the richness and complexity of their interconnections, the huge number of them, and the fact that they are accessed within atomic transactions. We propose three techniques to address these challenges: (1) using the database query language for hoarding; (2) using dependent commits to tentatively commit transactions at the disconnected client; (3) using the high-level semantic of objects to avoid transaction aborts.

Many client-server object-oriented database systems (OODBs) run applications at clients and perform all accesses on cached copies of database objects. Moving both data and computation to the clients can improve response time, throughput, and scalability. For applications with good locality of reference, retaining cached state across transaction boundaries can result in further performance and scaling benefits. This thesis examines the question of what concurrency control scheme is best able to realize these potential benefits. It describes a new optimistic concurrency control scheme called AOCC (Adaptive Optimistic Concurrency Control) and compares its performance with that of ACBL (Adaptive-Granularity Callback Locking), the scheme shown to have the best performance in previous studies. Like all optimistic schemes, AOCC synchronizes transactions at the commit point, aborting transactions when synchronization fails; ACBL, like other locking schemes, synchronizes transactions while they execute. Earlier