Application Controlled Data Persistence (ACDP)

Overview

This page describes some key characteristics of ACDP and a few features of its implementation in Java.

ACDP is the result of many years of ambivalent experience with SQL and relational database systems from different vendors in connection with the persistent storage of complex data structures. This is why this page ends with a few points of criticism regarding the use of common database management systems.

If your interest in ACDP is not satisfied after reading this page, you can follow the links in the colored header bar:

• Tutorial invites you to get your hands dirty and to learn in a playful way how to use Java ACDP and what you can do with it.
• Javadoc describes the API of Java ACDP in all details.
• License describes the conditions under which you can use the source code of Java ACDP.
• Download provides the source code of Java ACDP and the example used in the tutorial.
• About gives some information about me.

The remaining sections of this page are

Main Characteristics

• ACDP and the programs that access persistent data are written in the same programming language and preferably run in the same process.
• Navigational: Data can be efficiently accessed via references following the directed edges of an object graph.
• Built-in data types
  • include the array type
  • match the data types of the programming language
  • can be extended with customized data types
• Thanks to strongly typed tables, columns and values, robust persistence layers of multi-tier applications and services can be programmed relatively easily.
• No SQL: Queries are programmed.
• Currently, ACDP is only implemented in Java. See the feature list of Java ACDP below.

More Characteristics

• Writing program code for a data model described with a UML class diagram is straightforward.
• By bringing persistent data as close as possible to the programs that access them, ACDP facilitates the implementation of a service-oriented architecture in which data is read in a domain-specific context and exclusively changed in compliance with domain-specific constraints. This is in contrast to a dedicated DB server that accepts and processes SQL statements outside of a domain-specific context.
• Tables are sequences of rows and a row contains a sequence of values. If the same read-only query is executed twice, an iteration of the result returns the records in the same order.
• Transactions are never executed concurrently, but one after the other. As a result, clients do not have to expect ACDP to roll back unexpectedly, as is the case with traditional DBM systems when a deadlock must be prevented due to the concurrent execution of mutually interfering transactions.
• Nested transactions work as one would naturally expect.

Features of Java ACDP

• A database can be stored in the form of a single, highly compressed file and, as a read-only database, can be operated with excellent performance in main memory.
• Encryption can be enabled providing a customized cipher.
• Supports Java's streams API so that queries can be formulated in a functional style.
• Relies on Java's NIO package and thus on the performance of the file system of the underlying operating system.
• Does not use third-party Java libraries or program files (such as database drivers). There is no magical class enhancement, no leaky abstraction layer, no tricks, no excuses.
• Java ACDP is free of charge, open source, and licensed under the permissive Lida License.

Shortcomings with Database Management Systems

• DBMS and client often run in separate processes, so that the processes have to communicate with each other for each data exchange. If, in addition, DBMS and client run on dedicated servers, the servers must communicate with each other for each data exchange. All of this comes at a price and definitely does not reduce the error-proneness of the overall system.
• Operating a dedicated DB server tempts you to access the persistent data in an uncontrolled manner and to change data outside of a domain-specific context.
• Data types provided by the DBMS must be matched to data types provided by the programming language in which clients are written. Furthermore, the relational database model has no native array type.
• The relational database model and SQL are ideal when it comes to executing arbitrary ad hoc queries. However, in the realm of objects, data access does not naturally take place ad-hoc, but follows the directed edges of an object graph. The most effective way to implement a link from one object to another is to store a reference, just like objects are referenced in main memory. In the relational database model, however, the reference type is not intended.
• In the relational database model a relation consists of a set of tuples. The order in which the tuples of a relation are returned in the result of a query as well as the order, in which the values of a tuple are returned, is therefore undefined. If the same read-only query is executed twice, an iteration of the result may return the records in different orders.
• Object-relational mappers, so called ORMs, are to abstract from the relational database model. The popularity of ORMs shows that the use of RDBM systems is not ideal. However, ORMs themselves are a target of criticism, as can be seen on Wikipedia:

  Disadvantages of ORM tools generally stem from the high level of abstraction obscuring what is actually happening in the implementation code. Also, heavy reliance on ORM software has been cited as a major factor in producing poorly designed databases.

  Experience has shown me that an ORM actually slows down the underlying RDBMS in non-trivial scenarios even after numerous manual adjustments. In practice, an ORM cannot fulfill the promise of dealing only with an object model that abstracts from the underlying relational data model, especially if the data model is complex, i.e. precisely in those cases where such an abstraction would be particularly helpful.