Transcript OSCON 2003 JDO Talk

JavaPolis 2003
JDO
(Java Data Objects)
What It Is And Why It Matters
Ron Hitchens
[email protected]
http://www.ronsoft.com
JavaPolis 2003 - Antwerp, Belgium
Dec 3, 2003
7-11,
2003
© 2003,July
Ronsoft
Technologies
 Portland, Oregon
Purpose of this Presentation
To give you an introduction to JDO and show
that it represents a significant change in the
way that Java applications will manage their
data.
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Speaker Info




25+ years industry experience
6+ years using Java
Not a database expert
Built a website with JDO
(www.europeasap.com)
 O’Reilly author (Java NIO)
 Tech reviewer on JDO book
(Russell & Jordan)
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Bye bye SQL
JDO (or something like it) could
revolutionize the way applications
are created in the future.
http://www.ronsoft.com
© 2003, Ronsoft Technologies
What is JDO?
 Recently finalized 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 - datastore
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JVM
POJO
POJO
POJO
PM
POJO
Query
SPI
PM: Persistence Manager
POJO: Plain Old Java Object*
API: Application Programming Interface
SPI: Service Provider Interface
Persist
Datastore
* Implements PersistenceCapable at runtime
http://www.ronsoft.com
© 2003, Ronsoft Technologies
How JDO Works








Transparent Persistence
Persistence by Reachability
Object Lifecycle
Inheritance
Identity
Queries
Metadata
Restrictions
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Transparent Persistence
 Transparent to Persisted Objects
• No source code changes to needed to make objects persistent
• 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 persistent object state
• Object instances are per-PM – collisions in the datastore are
possible at commit
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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)
 PersistenceManager instances maintain
object caches, datastore access is
optimized where possible
http://www.ronsoft.com
© 2003, Ronsoft Technologies
PersistenceCapable
 The interface that all persistent
objects must implement at runtime
• Byte code enhancement
• Source code pre-processing
• Direct implementation by programmer
 PersistenceManager
• Primary access point to the JDO framework
• Operates on PersistenceCapable objects
• Maintains transaction context
 StateManager
•
•
•
•
Set per-object through the PersistenceCapable interface
Manages an object’s state while persistent
Mediates access to an object’s fields
SPI hook into runtime JDO Implementation
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Mediated Object Access
client
:PersistenceManager
myObject:
PersistenceCapable
implSM:
StateManager
makePersistent(myObject)
jdoReplaceStateMananger(implSM)
setFoo(12)
setIntField (this, n, foo, 12)
makeTransient(myObject)
jdoReplaceStateMananger(null)
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Persistence By Reachability
 A PersistenceCapable object instance is
either persistent or transient at any given
point in time
 All objects referenced directly or
indirectly by a persisted object are
automatically made persistent at
transaction commit.
• Persistence applies to the entire object graph
• Referenced non-PersistenceCapable objects are serialized
to the datastore
 Deletion from datastore is done per
object, not by reachability
• No datastore garbage collection
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Simple JDO Example
PersistenceManagerFactory factory = JDOHelper.getPersistenceManagerFactory(props);
PersistenceManager pm = factory.getPersistenceManager();
Transaction trans = pm.currentTransaction();
User user = new User ("ron", "Ron Hitchens", "[email protected]");
Address addr = new Address (“123 Main St.”, “Somewhere”, “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
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JDO Object Lifecycle (1)
POJO object instantiation
Transient
Object retrieved from datastore, instantiated by JDO
Read a field
Modify a field
Hollow
makePersistent()
Modify a field
Persistent New
Persistent Clean
Persistent Dirty
deletePersistent()
deletePersistent()
Persistent New
Deleted
deletePersistent()
http://www.ronsoft.com
Persistent Deleted
deletePersistent()
© 2003, Ronsoft Technologies
JDO Object Lifecycle (2)
Transaction Completion
commit(), rollback()
Persistent Clean
commit(), rollback()
Persistent Dirty
Hollow
Persistent Deleted
commit()
commit()
Persistent New
rollback()
commit(), rollback()
rollback()
http://www.ronsoft.com
Transient
Persistent Deleted
© 2003, Ronsoft Technologies
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.
 May be used to do cascading deletes
 Couples the object to JDO
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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 Class Table
 Interfaces may not be directly
persisted
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Queries

Three ways of retrieving objects
1.
2.
3.
Single object, by identity
Objects of a particular type – Extents
Objects whose fields contain specific values – Filters
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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);
}
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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();
}
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Queries – Filters
 Filters run against Extents
• Objects filtered are always of the type in the extent, possibly
including subclasses
 JDOQL – JDO Query Language
• Java-like syntax
• Parameters and variables may be supplied
• Datastore agnostic, references Java object fields
 Filters are applied by the Query class
• Returns a collection of matched objects
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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));
}
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JDO Metadata
 Provides mapping information to the JDO
implementation about classes and fields
 Standardized JDO descriptor (XML)
• Supplies information that cannot be determined by reflection
• Allows for override of defaults
• Provides for vendor extensions
 Can be used to automatically generate a
schema
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Object World
Object Types and Relationships
POJO
Database World
JDO
Metadata
How and where to store object data
JDO API
JDO Impl
POJO
Datastore
POJO
POJO
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JDO Restrictions
 Not all objects are persistable
• Streams, Sockets, many system classes, etc
 Collections must be homogenous
• Element type must be declared in metadata
 Maps may have restrictions on key types
 List ordering may not be preserved
 Objects cannot migrate between
PersistenceManager instances
 Persisted objects cannot outlive their
owning PersistenceManager
• No disconnect/reconnect semantics
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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
• One language - no embedded SQL in the Java code
 End-to-end OO design is possible – One
system architecture
 More agile – Datastore is an
implementation detail
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Why JDO Matters [2]
 Separation of Concerns
• Java Guy and DBA Guy do separate jobs
• No SQL strings buried in the Java code
• Leverage object persistence expertise of JDO implementors
 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 (“Maximize the work not done”)
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JDO and EJB
 Can JDO and EJB Co-exist?
• JDO can be used as a BMP strategy
- Sun’s SunOne App Server uses JDO for CMP
• 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
other J2EE container services
• Using JDO/BMP may be more cost-effective than paying for
full CMP capability
• Most Entity Beans uses are JDO-like anyway
- Aren’t distributed
- Don’t need access controls
- Aren’t remote
http://www.ronsoft.com
© 2003, Ronsoft Technologies
What’s Similar to JDO?
 CMP
 Proprietary O/R tools
• Toplink
• CocoBase
• Many others
 Open Source O/R tools
• Hibernate*
• Torque
• OJB
* Hibernate will have a JDO 2.0 binding
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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
http://www.ronsoft.com
© 2003, Ronsoft Technologies
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)
http://www.ronsoft.com
© 2003, Ronsoft Technologies
Questions?
Ron Hitchens
[email protected]
http://www.ronsoft.com
http://www.ronsoft.com
© 2003, Ronsoft Technologies
JavaPolis 2003
http://www.ronsoft.com
© 2003, Ronsoft Technologies