  |
|
+ @import url("./style/maven-theme.css");
|
In order to demonstrate compliance with the Java Data Objects specification, an implementation must pass all of the tests in the Technology Compatibility Kit (TCK). The TCK is released as a packaged Java source tree. Modified: db/jdo/site/docs/team-list.html URL: http://svn.apache.org/viewvc/db/jdo/site/docs/team-list.html?rev=1102276&r1=1102275&r2=1102276&view=diff ============================================================================== --- db/jdo/site/docs/team-list.html (original) +++ db/jdo/site/docs/team-list.html Thu May 12 13:06:20 2011 @@ -1,7 +1,7 @@
|
+ @import url("./style/maven-theme.css");
|
The people listed below have made significant contributions to JDO by working long and hard to make quality software for the rest of the world to use. Modified: db/jdo/site/docs/transactions.html URL: http://svn.apache.org/viewvc/db/jdo/site/docs/transactions.html?rev=1102276&r1=1102275&r2=1102276&view=diff ============================================================================== --- db/jdo/site/docs/transactions.html (original) +++ db/jdo/site/docs/transactions.html Thu May 12 13:06:20 2011 @@ -1,7 +1,7 @@
|
+ @import url("./style/maven-theme.css");
|
When managing the persistence of objects using a PersistenceManager it is normal to handle all datastore operations in a transaction. For this reason each PersistenceManager has its own transaction. Consequently a typical JDO persistence method Modified: db/jdo/site/docs/why_jdo.html URL: http://svn.apache.org/viewvc/db/jdo/site/docs/why_jdo.html?rev=1102276&r1=1102275&r2=1102276&view=diff ============================================================================== --- db/jdo/site/docs/why_jdo.html (original) +++ db/jdo/site/docs/why_jdo.html Thu May 12 13:06:20 2011 @@ -1,7 +1,7 @@
|
+ @import url("./style/maven-theme.css");
|
The majority of applications need to persist (or store) data during their lifecycle. There are many ways of doing this with an application written in Java.
+ Java Data Objects (JDO) is a specification begun in 2000, with 2 major releases + JDO1 (2002 under JSR0012) and JDO2 (2006 under JSR0243). It was placed under + Apache in 2005 and is the rare example of a specification that has undergone + continual improvement during its lifetime, for the last 4 years being developed + totally in the open, accepting input from everyone. +
++ JDO 3.0 was started in October 2008, and encompasses additions to the specification + in the areas of a metadata API, an enhancer API, addition of cancel/timeout control + to queries, and addition of control to the locking of objects when read. +
++ To persist Java objects you need to specify which classes are persistable, and + how they are persisted. This was traditionally handled using XML configuration. With + the advent of JDK1.5, annotations were added as another possible way of defining such + information. JDO 3.0 takes this further and provides a Metadata API, allowing + runtime definition. This is of particular use for systems that don't know at application + startup which classes should be persistable, maybe because the class hasn't been + written yet. +
++ To demonstrate the Metadata API, lets assume that we have a PersistenceManagerFactory + created for our datastore. So we request a new Metadata object. +
++ So we can now start defining the metadata for the package/class(es) we want to persist. + The Metadata is structured in a similar way to the XML DTD/XSD. So let's add a class +
++ So we have a class test.Client using datastore-identity, that is detachable, + and is persisted to a table CLIENT. As you can see, you can chain setters + for convenient coding. +
++ So we will use "new-table" inheritance for this class, and it will have a discriminator + stored in column disc of type "value-map". The class will also be versioned, using + column version, that is indexed. All of this was for the class as a whole, so let's + look at the fields/properties of the class. +
++ So we have a field name that is persisted into column name, and is unique + and indexed. The API metadata components all follow the DTD as stated earlier, so if + our field was a collection we could then define CollectionMetadata below it. +
++ The only thing left to do is register the metadata with the PersistenceManagerFactory, + like this +
++ and any contact with the class will now persist according to this API. +
++ You can similarly browse already registered metadata using +
++ Note that you cannot change already registered metadata with JDO 3.0. +
++ You can view the Javadocs for the Metadata API + here. +
++ JDO implementations typically (but aren't compelled to) include a bytecode enhancement + step, allowing for efficient change detection of objects. + While the Metadata API above is very useful, if we just define metadata for a class + we still need to enhance the class using this metadata. This is where the + Enhancer API comes in. To start we need to get a JDOEnhancer +
++ and now that we have the enhancer and want to enhance our class above so we + need to register our new metadata with it (generate the metadata as shown above) +
++ Now we can handle the enhancement using a separate class loader if required (for + example if the classes were defined dynamically, e.g by ASM) +
++ Finally we select what to enhance, and perform the enhancement +
++ So the class is now enhanced and is ready for use. +
++ You can view the Javadocs for the Enhancer API + here. +
++ On occasions a query may be inefficient, or may suffer from problems in the underlying + datastore, and so we don't want to affect the application. In this case it would make + sense to have control over a timeout for the query, or be able to cancel it. + JDO 3.0 introduces the Query cancel/timeout control, via the following new methods + to javax.jdo.Query +
++ So we have the ability to cancel a query as required, or just let it timeout. +
++ When we are using datastore (pessimistic) transactions it often doesn't make sense + to just lock all objects read in the transaction. For this reason JDO 3.0 introduces + control over which objects are locked and which aren't. +
++ In metadata for each class you can specify the "serialize-read" setting. + True will mean that objects of this type will be locked when read. +
++ On a Transaction you can override the metadata settings via the following + method +
++ On a Query you can override the metadata and Transaction settings via the following + method +
++ This concludes our simple overview of JDO3. We hope you enjoy using it +
+