EE Explorer: Persistent data management, part 1th

Data persistence is one of the toughest aspects of enterprise development. An enterprise data persistence solution must provide rapid client transactions that ensure data integrity over time and continue to exist as day-to-day disasters such as system crashes and network failures occur. In the next two parts of the Java Explorer series, we will focus on the Java EE technology, which helps you create a reliable data persistence solution for your enterprise architecture. We'll start with a brief introduction to data persistence in an enterprise application, and then continue to discuss the various technical options in more detail. In this section, we compare the one-stop (single-stop) solution of an entity bean with a more complex (but more robust) session Bean with a Java database connection (Java DB connectivity,jdbc) code. In the next section, we compare the Java Data Objects (Java OBJECT,JDO) with the entity bean.

What is data persistence?

Data is the most important aspect of any computer application program. The core of a computer application is to enable someone or another computer system to access its data. In an enterprise environment, data must be not only accessible (that is, connected to the user interface and managed by a series of business rules), but must also be persistent. Persistent data storage is the data store that can exist even if the server crashes.

Persistent data exists outside of the active memory of the application, typically in a database or flat file system. Although persistent data is read into the instantaneous memory for use or modification, it is always written to the external data store for long-term storage. The United States National Institute of Standards and Technology (United States Nation Institute of Standards and Technology) (see resources) defines three levels of persistent data:

Partial persistent data is a persistent structure that only allows updates to the latest version.

Persistent data is a data structure that retains its old version, that is, both previous and current versions may be queried.

Full persistent data is a persistent structure that maintains all versions of its data and allows updates to those versions.

Most business applications provide at least some persistent data. This type of persistence is vulnerable to a system failure in the middle of a transaction or even in the middle of a request, which can result in incomplete and often destroyed data. On the other hand, in a persistent data implementation, a "rollback (rollback)" response is made to a system outage or failure, and the data state is rolled back to the previous known Good configuration. Persistent data implementations are common in enterprise architectures and database management systems (DBMS). Fully persistent data implementations are rare. A few examples of fully persistent data implementations are: Logging file systems, VMS file systems (such as VAX and Mac OS X), and concurrent version control systems (CVS).

Persistence in the Java EE

The information age attaches great importance to the use of distributed enterprise computing platform. On such platforms, the data must be protected at any cost and persisted forever, even when faced with network failures, memory leaks, and server crashes. To maintain this persistence, application components must be capable of handling concurrency, connection management, data integrity, and synchronization. All three of Java EE's data management technologies handle these functions for developers, but each technique is slightly different in processing.

Entity Bean, which provides robust data persistence. The bean container handles most of the data integrity, resource management, and concurrency features, allowing developers to focus on business logic and data processing, rather than these low-level details. When using bean-managed persistence (Bean Managed persistence,bmp) entity beans, developers write persistent code and the container determines when the code executes. When using container-managed persistence (Container Managed persistence,cmp) entity beans, the container generates persistent code and manages the persistence logic.

JDBC, when the session bean is combined, provides easy EJB development and platform-independent deployments, without resource usage and memory overhead like EJB technology. Like a BMP entity bean, the solution requires developers to write persistent code. Unlike a BMP bean, it also requires developers to write persistent logic. Thus, the developer is responsible for determining when data is persisted in the data store and when data is loaded from the data store.

Java Data Objects are the newest persistence mechanism. JDO provides an object-oriented, persistent data store. Developers use POJO (unformatted normal Java objects, plain ordinary Java object) to mount and store persistent data.

We'll discuss the pros and cons of the entity Bean vs. session Bean and JDBC combination in the remaining articles.