As developers create more serious applications for the Web, the issues they face get tougher. One issue that is critical for business-level applications is data persistence.
Data persistence is the ability to keep data or information around even after a program ends. Because a browser is disconnected from a server, a program on the server can end; however, the user on the browser may still be using data from it. It is critical that the application running in the browser not only appears continuously connected, but that it also operates as if it were connected.
Data persistence has several issues. First, when sustaining data, you want to make sure that multiple users can still access the data. Just because I’m viewing data on my browser doesn’t mean that others can’t be viewing or modifying it as well.
Another issue that must be addressed regarding data persistence is that of transactional access. For real-world applications, you must deal with data in a transactional method. It is transactions that allow multiple people to work on the same data or program without worrying about “stomping” on each other. For example, you and I both grab a record containing “book” information. We grab it at the same time. You make a change to the price from $19.99 to $24.99 and save it. I make a change from the price of $19.99 to $17.99 and save my change after yours was changed. What should happen? If my change is saved, then your change was totally wiped ignored. Transactional processing puts into place a structure that would prevent my change from happening without first showing that the original price of $19.99 had been changed by someone else (you). Transactional processing is also important when multiple changes must occur. For example, if I buy a book, the first step is to change inventory to show that the book is being purchased. This prevents someone else from buying it. A second step would be to get a payment from me. If my payment fails, you don’t want to simply quit. Rather, you need to make sure the book ends up back in inventory. Transactional processing will take care of this for you.
A third issue with persistence deals with portability and ease of use. When you start coding solutions for persistence, you often limit a program’s portability to specific environments. Additionally, the efficiencies and ease of use of the program begin to become complicated.
Currently data is sustained in a number of ways. Most of the time these solutions are proprietary and thus not portable beyond the current application without added work. Such proprietary methods may include direct file I/O where the program contains code that writes and reads the information as needed. It also would contain code to deal with the transactional aspects of the application. This may involve serialization, the use of JDBC, or even JavaBeans in a java solution. Many of these solutions have issues. For example, serialization does not allow for partial reads or writes, nor does it provide transactional support. JDBC is generally not portable due to the various flavors of SQL. Using EJB is not a full solution because there are limited objects, plus several platforms, such as embedded and two-tier are not supported.
For Java developers, there is a new way to implement data persistence. Java Data Objects (JDO) is a Java-based solution to help solve data persistence in java systems. JDO can be defined as:
A standardized, transparent persistence for Java objects. JDO is a common (vender neutral), Java centric view of a data storage system.
Java Data Objects are a pure Java API. Unlike SQL, this is not a language tied to a database. JDO provides a number of features including:
In summary, JDO provides a “programmer’s way” of accessing databases from a Java application. It takes care of data persistence for the programmer, it allows for transactional processing, and it provides an interface so the underlying data source can be changed without re-writing your applications. # # #