J2EE Explorer: persistent data management, part 1

The J2EE platform provides a rich set of options for managing enterprise data persistence. But how do you choose the options that suit your architecture? Kyle Gabhart introduced the best J2EE data persistence technology-entity beans, JDBC, and JDO-and compared them in several different environments.
Data persistence is one of the most difficult aspects in enterprise development. An enterprise data persistence solution must provide rapid client transactions to ensure data integrity over time and to continue to exist in the event of daily disasters such as system crashes and network failures. In the next two sections of the J2EE Explorer series, we will focus on J2EE technologies that help you create reliable data persistence solutions for your enterprise architecture. We will start this topic by briefly introducing data persistence in enterprise applications, and then continue to discuss various technical options in more detail. In this section, we will compare the one-stop (single-stop) solution of entity beans with the more complex (but more robust) session beans connected to Java databases (Java Database Connectivity, JDBC) code combination. In the next section, we will compare Java Data Objects (JDO) and Object beans.
What is data persistence?
Data is the most important aspect of any computer application. The core of computer applications is to allow someone or another computer system to access their data. In an enterprise environment, data must not only be accessible (that is, be connected to the user interface and managed according to a series of business rules), but also be persistent. Persistent data storage is a data storage that can exist even when the server crashes.
Persistent data exists outside the active memory of an application, usually in a database or flat file system. Although persistent data is read into instantaneous storage for use or modification, it is always written to external data storage for long-term storage. The United States National Institute of Standards and Technology defines three levels of persistent data:
Partial persistent data is a persistent data structure that only allows updates to the latest version.
Persistent data is a data structure that retains the old version, that is, both previous and current versions may be queried.
Full persistent data is a persistent data structure that maintains all versions of its data and allows updates to these versions.
Most business applications provide at least some persistent data. This type of persistence is vulnerable to damage in the middle of a transaction or even when a system failure occurs in the middle of a request, resulting in incomplete data and frequent destruction. On the other hand, in the implementation of persistent data, a "rollback" response is made to system interruptions or failures, and the data status is rolled back to the previous known good configuration. Persistent data implementation is common in enterprise architecture and database management systems (DBMS. Completely persistent data implementation is rare. A few examples of fully persistent data implementation are: log recording file systems, VMS File systems (such as VAX and Mac OS X), and concurrent version control systems (CVS ).