320 likes | 463 Views
JDO (Java Data Objects) What It Is And Why It Matters Ron Hitchens ron@ronsoft.com http://www.ronsoft.com. Speaker Info. 25+ years industry experience 6+ years using Java Built a website with JDO (www.europeasap.com) O’Reilly author (Java NIO) Tech reviewer on JDO book (Russell & Jordan).
E N D
JDO(Java Data Objects)What It Is And Why It MattersRon Hitchensron@ronsoft.comhttp://www.ronsoft.com
Speaker Info • 25+ years industry experience • 6+ years using Java • Built a website with JDO (www.europeasap.com) • O’Reilly author (Java NIO) • Tech reviewer on JDO book (Russell & Jordan)
What is JDO? • New Java standard extension • JSR 12 (http://jcp.org) • Transparent object persistence • No code changes to persisted objects • Standardized API • Vendor neutral • Datastore neutral • Not an object database • May use conventional RDBMS, OODB or other means to store object data
JVM POJO POJO JDO API JDO Impl POJO PM Query POJO SPI Persist Datastore PM: Persistence Manager POJO: Plain Old Java Object API: Application Programming Interface SPI: Service Provider Interface
How JDO Works • Transparent Persistence • Persistence by Reachability • Object Lifecycle • Inheritance • Identity • Queries • Metadata • Restrictions
Transparent Persistence • Transparent to Persisted Objects • No source code changes to persistent objects needed • Clients are unaware an object is persistent • Persisted objects are auto-loaded when referenced • Not Transparent to Entire Application • JDO APIs are used to manage and query for objects • Transaction boundaries affect object state • Object instances are per-PM – collisions are possible at commit
Transparent Data Access • Objects and object fields are lazy-loaded when referenced • Changes to object state result in eventual updates to datastore without explicit saves (subject to transaction boundaries) • PersistenceManagers maintain object caches, datastore access is optimized where possible
PersistenceCapable • The interface that all persistent objects must implement at runtime • Byte code enhancement • Source code pre-processing • Direct implementation by programmer • StateManager • Set through PersistenceCapable interface • Manages object’s state while persistent • Mediates access to object fields • SPI hook into runtime JDO Implementation
Mediated Object Access client :PersistenceManager myObject: PersistenceCapable implSM: StateManager makePersistent(myObject) jdoReplaceStateMananger(implSM) setFoo(12) setIntField (this, n, foo, 12) makeTransient(myObject) jdoReplaceStateMananger(null)
Persistence By Reachability • All objects referenced directly or indirectly from a PersistenceCapable object are automatically persisted at transaction commit. • Persistence applies to entire object graph • Referenced non-PersistenceCapable objects are serialized to the datastore • Deletion is done per object, not by reachability • No datastore garbage collection
Simple JDO Example PersistenceManagerFactory factory = JDOHelper.getPersistenceManagerFactory(props); PersistenceManager pm = JDOFactory.getPersistenceManager(); Transaction trans = pm.currentTransaction(); User user = new User ("ron", "Ron Hitchens", "ron@ronsoft.com"); Address addr = new Address (“123 Main St.”, “Smallville”, “CA”, “12345”); user.setAddress (addr); trans.begin(); pm.makePersistent (user); trans.commit(); pm.close(); • Two objects were persisted: • The instance of User explicitly made persistent • The Address instance reachable from user
JDO Object Lifecycle (1) POJO object instantiation Object retrieved from datastore, instantiated by JDO Transient Read a field Hollow Modify a field makePersistent() Modify a field Persistent New Persistent Clean Persistent Dirty deletePersistent() deletePersistent() Persistent New Deleted Persistent Deleted deletePersistent() deletePersistent()
JDO Object Lifecycle (2) Transaction Completion Persistent Clean commit(), rollback() commit(), rollback() Persistent Dirty Hollow rollback() Persistent Deleted commit() Persistent New commit() commit(), rollback() rollback() Transient Persistent Deleted
Lifecycle Callbacks • An object may optionally implement the InstanceCallbacks interface • jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete() • May be used to release resources when an object is going hollow • May be used to reconstitute transient values that can be recalculated from persisted fields. • Couples the object to JDO
Inheritance • Polymorphism is supported • Base type must be PersistenceCapable • Persistent super classes must be listed in metadata definition • Queries may return subclasses, if requested • Implementation defines table mapping strategy • Single Table, Class Table, Concrete Table • Interfaces may not be directly persisted
JDO Identity • Each Persistent Object has a unique JDO Identity • Not the same as Java identity • JDO Identity is encapsulated as an Object • One instance per identity per PersistenceManager • Datastore Identity vs. Application Identity • Datastore Identity assigned automatically • Application Identity defined by programmer • Persisted objects are retrieved by their identity
Queries • Three ways of retrieving objects • Single object, by identity • Objects of a particular type – Extents • Objects whose fields contain specific values – Filters
Queries – Single Object By ID Customer getCustomerByIdString (String idStr, PersistenceManager pm) { Object id = pm.newObjectIdInstance ( Customer.class, idStr); Object customer = pm.getObjectById (id, true); return ((Customer) customer); }
Queries – Extent • A collection-like object representing a set of persistent objects, of a specified type, in the datastore • May contain subclasses, if requested Extent e = pm.getExtent (Customer.class, true); Iterator it = e.iterator() while (it.hasNext()) { Customer customer = (Customer) it.next(); customer.computeDailyInterest(); }
Queries – Filters • Filters run against Extents • Objects filtered are always of the type in the extent, possibly subclasses • JDOQL – JDO Query Language • Java-like syntax • Parameters and variables may be supplied • Datastore agnostic, references Java fields • Filters are applied by Query class • Returns a collection of matched objects
Queries – Filter Example Collection getCustomersByCity (City city, PersistenceManager pm) { Extent extent = pm.getExtent (Customer.class, true); String filter = “address.city == city”; Query query = pm.newQuery (extent, filter); query.declareParameters (“City city”); query.setOrdering (“name ascending”); return (query.execute (city)); }
JDO Metadata • Provides mapping information to JDO implementation about classes and fields • Standardized JDO descriptor (XML) • Provides information that cannot be determined by reflection • Allows for override of defaults • Provides for vendor extensions • Can be used to generate a schema
JDO Metadata Object World Database World Object Types and Relationships How and where to store object data JDO Impl JDO API POJO POJO POJO Datastore POJO
JDO Restrictions • Not all objects are persistable • Streams, Sockets, many system classes, etc • Collections must be homogenous • Maps may have restrictions on keys • List ordering may not be preserved • Objects cannot migrate between PersistenceManager instances • Persisted objects cannot outlive their owning PersistenceManager
Why JDO Matters [1] • The Object Model IS the Data Model • Datastore is one component in the system, not the center of the universe • Promotes datastore independence at design, development and deploy times • End-to-end OO design is possible – One system architecture • More agile – Datastore is an implementation detail
Why JDO Matters [2] • Separation of Concerns • Java Guy and DBA Guy do separate jobs • No SQL strings buried in the Java code • Cost • Standard API – Leverage developers • Lightweight – No special container needed • Competition among compliant vendors • Legacy databases can be wrapped by JDO objects • Less work to do overall
JDO and EJB • Can JDO and EJB Co-exist? • JDO can be used as a BMP strategy • Sun’s SunOne App Server does this • JDO can plugin to any JCA compliant App Server and participate in managed transactions • Layered architecture • One app may use JDO objects directly • Another may use the same objects within EJBs to leverage J2EE container services • Using JDO/BMP may be more cost-effective than paying for full CMP capability
What’s Similar to JDO? • CMP • Proprietary O/R tools • Toplink • CocoBase • Many others • Open Source O/R tools • Hibernate • Torque • OJB
Where Can I Get JDO? • JDO Vendors • Solarmetric (www.solarmetric.com) • Libelis (www.libelis.com) • JDO Genie (www.hemtech.co.za/jdo/) • Poet FastObjects (www.fastobjects.com) • Open Source Options • Apache OJB (db.apache.org/ojb/) • JORM (www.objectweb.com/ • See www.jdocentral.com for more
Where Can I Get More Info? • Web Resources • http://access1.sun.com/jdo/ • http://www.jdocentral.org/ • http://jdo-tools.sourceforge.net/ • http://groups.yahoo.com/JavaDataObjects • http://onjava.com (search for JDO) • Google “Java Data Objects” • Publications • Java Data Objects (Russell & Jordan) • http://www.oreilly.com/catalog/jvadtaobj/ • Java Data Objects (Roos)
Questions? Ron Hitchensron@ronsoft.comhttp://www.ronsoft.com