Objects contain the possibility of all situations.
If RAM were unlimited and computers never shut down, you would now have all of the tools you need to finish the server side of the banking application. You cannnot, however, afford to have all your data in memory all of the time; computers shut down far too often, sometimes by design, sometimes by error. You need to grant your business objects a certain level of immortality, to make them persist beyond the lifecycle of the process in which they are created.
Persistence is the act of making the state of an application stretch through the end of this process instance of the application to the next. In order to make an application persist, its state needs to be recorded in a data store that can survive computer shutdowns and crashes. The most common persistence tool is by far the relational database—and for Java, that means JDBC.
Transactions appear throughout this book. In the first half of this book, you saw how JDBC manages transaction isolation levels, commits, and rollbacks. Chapter 8, spoke of component-level transactions. You now need to tie the two together at the persistence layer.
The component transaction choreographs a persistence operation. When that transaction is notified that it is complete, it creates a persistence transaction—in your case, a JDBC transaction—and tells each object modified in the business transaction to ...