Approaches to Persistence in Java

1. Approaches to Persistence in Java Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822

2. Small scale persistence: dozens to hundreds of users single machine All persistent objects can fit in memory at once. No transaction, rollback, fail-over Cheap and fast to implement Large scale persistence: thousands to millions of users clusters of machines, shared caching lazy/incremental loading of objects Transaction, rollback, fail-over required Costly and time-consuming to implement Part 1: Small Scale Persistence

3. Common motivations • Persistence across application restarts/failure • Avoid data loss • Checkpoints • Allow rollback to previous state • Transfer of data between multiple applications • Synchronous vs. asynchronous • Example: network vs. file system • Application-specific vs. portable • Example: Serialized object vs. XML • Caching of intermediate results • Avoid computation loss

4. Simple, key-value: java.util.Properties java.util.prefs package JNDI Object-based: java.io.Serializable JavaBean persistence Java Data Objects (JDO) XML-based: JDOM JAXB Database: Relational Object-oriented Enterprise Java Beans: Entity & Session beans CMP & BMP Some flavors of persistence

5. Persistence creates development issues • Persistence tends to slow down development. • Adds cost & risk to major design changes. • Tends to “lock in” early (bad) design decisions. • Why is persistence a problem? • The Object-Relational Impedance Mismatch • Multiple design issues and constraints • How can we maintain development velocity in face of need for persistence? • A “Late-binding persistence” development strategy

6. Object-Relational Impedance Mismatch • Object paradigm: • Networks of objects with state and behavior • Processing via: traversal • Classes, inheritance, polymorphism, etc. • Relational paradigm: • Tables of entities with only data. • Processing via: selection/joining of rows • Tables, columns, keys, indices, etc. • The intrinsic differences between paradigms creates design problems.

7. Example • Consider a family tree. • Consider the query “Return all of the grandchildren of Family Member X” • Which representation would make this query easiest to implement? • A network (tree) of family members • A set of database tables and SQL statements

8. Addressing the OO-DB IM • 1. Eliminate the OO: • User interface manipulates SQL. • Pros: single paradigm, simplicity • Cons: complexity of “advanced” processing (stored procedures, etc.) • 2. Eliminate the relational DB: • OODBs, Serialized objects, etc. • Pros: single paradigm, simplicity • Cons: potential loss of relational data integrity (normalization)

9. Addressing the OO-DB IM • 3. Hide the DB: • Object-to-relational mappings, JDO, EJB... • Pros: Allows use of back-end RDBMs • Cons: Complexity, lock-in, overhead • 4. Stop whining and just deal with it: • Manual mapping between objects and tables • Pros: Flexibility • Cons: Maintenance and complexity

10. Simplicity: How complicated to set up for me? For my users? Financial cost: Do I have to pay for it? Do my users? Data specificity: What kinds of data am I saving? Can I use a “special purpose” persistence mechanism? Design lock-in: How much code will I have to change if I need to change my mechanism? Longevity: How long must the persistent data exist? Scalability: What usage level do I expect over the next six months? Integrity: Do I require transactions? Rollback? Fail-over? OO-Relational impedance mismatch: Do I mind the cost? Optimization: Do I need something faster than a relational database? Choice of persistence depends upon many design issues

11. One development approach:Late-binding persistence • Initial development: No persistence. • Deploy initial versions to user on “trial basis” with no persistence guarantees. • Early “live” releases: simple, “non-scalable”. • Enable data migration. • Determine true bottlenecks/integrity issues. • Maintain application evolvability. • Ongoing development: • Think about multiple persistence approaches. • Example: Preferences + XML + RDMS • Each approach optimized to persistence requirements. • Applicability of this approach depends upon nature of system/requirements!

12. A birds-eye view of selected persistence mechanisms

13. Preference and configuration data • java.util.Properties: • Well known, easy to use • No standards as to where data should reside • Problems for backup, or transfer to other machines. • JNDI (Java Naming and Directory Service): • Back-end neutrality • Large, complicated to set up • java.util.prefs (JDK 1.4): • Back-end neutrality of JNDI • Simplicity of java.util.Properties • Can be invoked by multiple threads safely

14. Object-based persistence:java.io.Serializable • Pros: • Converts an object (and all internal objects) into a stream of bytes that can be later deserialized into a copy of the original object (and all internal objects). • Fast, simple, compact representation of an object graph. • May be great choice for *temporary* storage of data. • Cons: • Creates long-term maintenance issues • Harder to evolve objects and maintain backward compatibility with serialized representation. • See “Effective Java”, Chapter 10, for a good description of issues with Serialization

15. XML file-based persistence: JDOM and JAXB • Pros: • Very high level of data portability. • Simple • Cons: • Space-inefficient • Complex graph structures problematic. • For data structures: • JDOM • For bi-directional object mappings: • JAXB

16. Java-based RDBMS • Most important one is Derby. • http://db.apache.org/derby • Will be included in JDK 1.6! • Can run as either ‘embedded’ in your application JVM or as a stand-alone network server. • To embed, just add derby.jar to your classpath!

17. Open Source Java Persistence Frameworks • Hibernate (www.hibernate.org): • Object to RDBMS binding • “Hibernate Query Language” • Claims to be very fast, very scalable, very efficient. • Most popular open source framework for object/relational mapping in Java.

18. Others • Enterprise Java Beans • Public standard framework • Simple reference implementation • Support for clustering, fail-over, etc. in distributed applications. • Firestorm/DAO • Automatically generates Java source code for accessing relational databases.

19. Things to think about • Sometimes simple is better • Try the least complicated persistence mechanism first. • Sometimes you can mix and match • Not all data must necessarily be persisted the same way • You can evolve your solution over time • Especially if you design your system to encapsulate your persistence mechanism.

20. Things to think about • Your persistence strategy might depend on context: • Java First: • You’ve developed/inherited some Java code and need someplace to store the objects. • Hibernate • Database First: • You’ve developed/inherited a database and want to access it in Java. • Firestorm/DAO • Spaghetti Junction: • You’ve inherited Java code and a DB and want to put the two together. • Uh oh.

21. Things to think about • IF: Client-side, single thread, simple structure, installation simplicity • DB optional, consider XML. • IF: Multiple clients need access to data • DB highly recommended • IF: Transaction support, fail-over, etc: • DB required