The two-decade long history of events relating object-oriented programming, the development of persistence and transactional support, and the aggregation of multiple nodes in a single-system image cluster, appears to convey the following conclusion: programmers ideally would develop and deploy applications against a single shared global memory space (heap of objects) of mostly unbounded capacity, with implicit support for persistence and concurrency, transparently backed by a possibly large number of clustered physical machines.

In this paper, we propose a new approach to the design of OODB systems for Java applications: (O3)2 (pronounced ozone squared). It aims at providing to developers a single-system image of virtually unbounded object space/heap with support for object persistence, object querying, transactions and concurrency enforcement, backed by a cluster of multi-core machines with Java VMs that is kept transparent to the user/developer. It is based on an existing persistence framework (ozone-db) and the feasibility and performance of our approach has been validated resorting to the OO7 benchmark.

Several decades ago, the file system was the container of choice for large bulks of related information, kept in hundreds of files, and relying on applications specifically created to handle them. These configurations weren't scalable and could easily become difficult to maintain, leading to the development and adoption of Database Management Systems (DBMS). These systems, capable of efficiently handling vast amounts of data, allowed heavy concurrency without requiring the programmer to deal with concurrency-control mechanisms, by encapsulating operations within transactions.
The properties of Transactions rapidly became an object of desire by many, and efforts to bring them to general-purpose programming environments began. In recent years there have been breakthroughs in bringing the transactional semantics to memory, using Software Transactional Memory (STM), providing abstractions to concurrency-control on the application-level. However, STM failed to meet some expectations, specially regarding I/O operations, forcing the abstraction to go deeper in the system: directly to the file system.
In this document we shall discuss file systems in general, their properties and common structure, although focusing in those with transactional or versioning capabilities. Later on, we will present our proposed enhancement of an existing Linux file system (Btrfs), in order to offer transactional semantics to applications, while detecting potential conflicts between concurrent flows of execution and reconciling their changes whenever possible.