Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
A good example of a first-class object: an object of class
Order usually has one or more instances of
OrderLine is a second-class object example.
Now, I'll detail the specification's major public interfaces:
PersistenceManager instances for application use. It also lets application developers configure the persistence layer behavior -- set transaction
options, perform connection pool administration, and so on.
In a managed environment, the application uses JNDI (Java Naming and Directory Interface) lookup to retrieve an environment-named
object, which is then cast to
PersistenceManager provides the primary interface for JDO-aware application components.
PersistenceManager administers persistent instances' lifecycles, and provides transaction and cache management. It also acts as the
Query interface's factory.
As mentioned before, any user domain class must implement the
PersistenceCapable interface. Note: There are no special methods for persistence; the
PersistenceCapable interface is really empty. You can implement this interface in one of three ways: through source code, an enhancer, or generation
Persistence operations usually occur within a transactional context. A one-to-one relationship exists between the
PersistenceManager and the
Transaction. In managed environments, the container provides actual transaction services, but the
Transaction interface provides methods for managing transaction options. In a standalone environment, the
Transaction implementation, provided by the JDO software vendor, must ensure a successful transaction -- commit or rollback.
Cache management and JDO instance lifecycle
Every JDO object (instance) goes through a series of state changes in its lifetime. The Sun JDO specification defines 10 JDO instance states. It requires seven transactional instance states (the remaining three are optional):
makePersistent()method or when referenced by a persistent instance's persistent field after that same instance commits.
For more information regarding state transitions and JDO instances' persistence states, consult the Sun JDO spec.
An important part of every data manipulation subsystem is its query language. In the Sun JDO, the
PersistentManager instance is a factory for query instances, and queries execute in the context of the
Queries must conform to the Object Query Language (OQL) grammar, defined in the Object Management Group (OMG) 3.0 OQL Specification. The JDO OQL resembles SQL, except that it operates on Java classes and objects, not tables. A JDO OQL query has at least three elements:
Optional query elements include the following:
Query filters can be the following:
||, and so on). Of course not all Java operators make sense for data selection.
Please consult the JDO spec for more details regarding queries.
Below is a JDO query example:
// Example of a query Class target = Employee.class; Extent extent = pm.getExtent (target, false); String filter = "getEmpId () >= 1 && getEmpId () <= 10"; Query query = pm.newQuery (extent, filter); query.setClass (target); query.compile (); Collection result = (Collection) query.execute ();
Let's see how the Sun JDO compares to the ideal persistence layer presented in Part 1. As you might recall, the desirable traits I outlined include the following (Note: I reference only the most important features):
The Sun JDO's major advantage: it provides a unified, standard persistence interface supported by multiple vendors delivering competing implementations. Another advantage is its transparency, or its data-store type independence.
The Sun JDO almost fulfils the simplicity trait, the only offending part being the OQL Query specification, which could be
simplified. Sun also fails to offer minimal intrusion. In addition, Sun's JDO could do without the class enhancer or the obligatory
Some designed-by-committee traits are also evident: The API is not always consistent. Also, specification development progresses slowly; Sun JDO has been in draft form for several months now.
Overall, however, its standard persistence interface and transparency really set the tone for the Sun JDO. Its future looks quite bright.
Castor is an open source data-binding framework for Java. Castor's multiple projects target mapping between Java objects, XML documents, SQL tables, and LDAP (lightweight directory access protocol) directories. The Castor JDO project focuses on the Java object persistence-to-relational data stores. Despite its name and resemblance, Castor JDO is not compatible with Sun's spec. Note: Because Castor JDO concentrates on relational data stores exclusively, it does not support data-storage type transparency. Among the nonproprietary API (open source or multivendor) solutions available, the Castor JDO feature set is more than sufficient for most projects, and the price can't be beat.