Modified: websites/production/db/content/jdo/tck.html ============================================================================== --- websites/production/db/content/jdo/tck.html (original) +++ websites/production/db/content/jdo/tck.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,63 +210,63 @@
- - - - -

About the Technology Compatibility Kit

- -

- 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. - Maven is the driver of a test run. You must download and install - Maven 2+before running the TCK. -

-
- -

Running the TCK

-

- To run the Technology Compatibility Kit: -

-
    -
  1. - Check out the JDO source code from the most recent branch. See Source Code for instructions on checking out code. -
  2. -
  3. - Follow the instructions in the Prerequisites section of - README.html. -
  4. -
  5. - Follow the procedure in RunRules.html in the jdo2-tck-version directory. -
  6. -
-
- -

Demonstrating Compliance

-

-Vendors must post test results on a publicly accessible web site for -examination by the public. The posting includes the output of the -test run, which consists of multiple log files containing -configuration information and test results. For an example of the -required posting, please see http://db.apache.org/jdo/tck/final. -

-
- - + + + + +

About the Technology Compatibility Kit

+ +

+ 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. + Maven is the driver of a test run. You must download and install + Maven 2+before running the TCK. +

+
+ +

Running the TCK

+

+ To run the Technology Compatibility Kit: +

+
    +
  1. + Check out the JDO source code from the most recent branch. See Source Code for instructions on checking out code. +
  2. +
  3. + Follow the instructions in the Prerequisites section of + README.html. +
  4. +
  5. + Follow the procedure in RunRules.html in the jdo2-tck-version directory. +
  6. +
+
+ +

Demonstrating Compliance

+

+Vendors must post test results on a publicly accessible web site for +examination by the public. The posting includes the output of the +test run, which consists of multiple log files containing +configuration information and test results. For an example of the +required posting, please see http://db.apache.org/jdo/tck/final. +

+
+ +
Modified: websites/production/db/content/jdo/team-list.html ============================================================================== --- websites/production/db/content/jdo/team-list.html (original) +++ websites/production/db/content/jdo/team-list.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -12,7 +12,7 @@ - + @@ -210,71 +210,71 @@
- - - - -

The Apache JDO Team

- -

- 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. -

- -

- If you would like to contribute to JDO, please see the - roadmap list to find areas where you - can contribute. - If there is nothing in there that suits your interest, but you still have - ideas, please feel free to suggest them on the mailing list. -

-

- If you would like to become a committer, please see - Get Involved. -

- -
-

Apache JDO Committers

- - - - - - - - - - - - - - - -
NameOrganization
Matthew AdamsSpringSource
Erik BengtsonJPOX
Michael BouschenTech@Spree
Michelle CaisseSun Microsystems, Inc.
Andy JeffersonDataNucleus
Patrick LinskeyOracle
Geir Magnusson Jr.IBM
Brian McCallister
Craig RussellSun Microsystems, Inc.
Dain Sundstrom
Brian Topping
Michael WatzekTech@Spree
Martin ZaunSun Microsystems, Inc.
-
- -

Apache JDO Contributors

- - - - -
NameOrganization
Chris BeamsSpringSource
Ilan KirschObjectDB
-
- + + + + +

The Apache JDO Team

+ +

+ 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. +

+ +

+ If you would like to contribute to JDO, please see the + roadmap list to find areas where you + can contribute. + If there is nothing in there that suits your interest, but you still have + ideas, please feel free to suggest them on the mailing list. +

+

+ If you would like to become a committer, please see + Get Involved. +

+ +
+

Apache JDO Committers

+ + + + + + + + + + + + + + + +
NameOrganization
Matthew AdamsSpringSource
Erik BengtsonJPOX
Michael BouschenTech@Spree
Michelle CaisseSun Microsystems, Inc.
Andy JeffersonDataNucleus
Patrick LinskeyOracle
Geir Magnusson Jr.IBM
Brian McCallister
Craig RussellSun Microsystems, Inc.
Dain Sundstrom
Brian Topping
Michael WatzekTech@Spree
Martin ZaunSun Microsystems, Inc.
+
+ +

Apache JDO Contributors

+ + + + +
NameOrganization
Chris BeamsSpringSource
Ilan KirschObjectDB
+
+
Modified: websites/production/db/content/jdo/transactions.html ============================================================================== --- websites/production/db/content/jdo/transactions.html (original) +++ websites/production/db/content/jdo/transactions.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -11,7 +11,7 @@ @import url("./css/site.css"); - + @@ -209,51 +209,51 @@
- - -

Transactions

-

- 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 - will look something like this -

-
-PersistenceManager pm = pmf.getPersistenceManager();
-Transaction tx = pm.currentTransaction();
-try
-{
-    tx.begin(); // Start the PM transaction
-
-    ... perform some persistence operations
-
-    tx.commit(); // Commit the PM transaction
-}
-finally
-{
-    if (tx.isActive())
-    {
-        tx.rollback(); // Error occurred so rollback the PM transaction
-    }
-}
-

- JDO supports the two main forms of transaction -

-
    -
  • Transactions can lock all records in a datastore and keep them locked until they are - ready to commit their changes. These are known as Pessimistic (or datastore) - Transactions
  • -
  • Transactions can simply assume that things in the datastore will not change until they - are ready to commit, not lock any records and then just before committing make a check - for changes. These are known as Optimistic Transactions.
  • -
-

- You select the type of transaction to be used by a PersistenceManager (PM) either by - setting the PMF property javax.jdo.option.Optimistic, or on the transaction you call -

-
pm.currentTransaction().setOptimistic(true);
-
- + + +

Transactions

+

+ 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 + will look something like this +

+
+PersistenceManager pm = pmf.getPersistenceManager();
+Transaction tx = pm.currentTransaction();
+try
+{
+    tx.begin(); // Start the PM transaction
+
+    ... perform some persistence operations
+
+    tx.commit(); // Commit the PM transaction
+}
+finally
+{
+    if (tx.isActive())
+    {
+        tx.rollback(); // Error occurred so rollback the PM transaction
+    }
+}
+

+ JDO supports the two main forms of transaction +

+
    +
  • Transactions can lock all records in a datastore and keep them locked until they are + ready to commit their changes. These are known as Pessimistic (or datastore) + Transactions
  • +
  • Transactions can simply assume that things in the datastore will not change until they + are ready to commit, not lock any records and then just before committing make a check + for changes. These are known as Optimistic Transactions.
  • +
+

+ You select the type of transaction to be used by a PersistenceManager (PM) either by + setting the PMF property javax.jdo.option.Optimistic, or on the transaction you call +

+
pm.currentTransaction().setOptimistic(true);
+
+
Modified: websites/production/db/content/jdo/why_jdo.html ============================================================================== --- websites/production/db/content/jdo/why_jdo.html (original) +++ websites/production/db/content/jdo/why_jdo.html Sat Feb 23 14:12:18 2013 @@ -1,5 +1,5 @@ - + @@ -11,7 +11,7 @@ @import url("./css/site.css"); - + @@ -209,164 +209,164 @@
- - -

Why JDO ?

-

- 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. -

-
    -
  • If your datastore is RDBMS you can handle the persistence (and retrieval) of data yourself - using JDBC. Obviously with this route you have the burden of having to write the - persistence layer yourself. This gives much control, but also creates significant work, - both in writing the code but also in testing and maintenance.
  • -
  • You can use JDO, a standardised persistence API. With JDO you can develop - plain old java objects (POJOs) and persist them as they are transparently. This requires - very little work from the developer. It allows persistence to any type of datastore in - principle, being designed with flexibility and datastore agnositicity in mind. - This has been a standard since 2002 (JDO1), being upgraded in 2006 (JDO2) and - is in the process of being developed further (JDO2.1) by Apache JDO
  • -
  • You can use JPA, a standardised persistence API, and part of the EJB3 specification. This also allows you to - to develop plain old Java objects (POJOs) and persist them using a standardised API. It's specification - is not as mature or as feature rich as the JDO API, nor does it provide the flexibility - of using any type of datastore. This was released in 2006 (JPA1) to supercede EJB2. It really - only allows persistence to RDBMS datastores. If you want to persist to other datastores - you should consider JDO.
  • -
  • If you are stuck with using an EJB2.* architecture you could use Entity Beans. This - means that you hand off your objects to the EJB part of the J2EE server. This simplifies - things for the developer in some respect but places major restrictions in that your objects - have to be Entity Beans.
  • -
  • You can also use a proprietary persistence API (e.g Hibernates own API, TopLinks own API, iBatis, Castor etc). - The disadvantages of going this route are that you cannot easily swap to an alternative - implementation of the API if you hit problems with your software choice.
  • -
-

- To give a guide, here are a few important consideration points when choosing a persistence layer for your application. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FeatureJDBCJDOJPAEJB2Custom ORM
Standards-Driven
Choice of datastores
Support POJOs
Usable in J2SE
Usable in J2EE
Out of box implementation (1)
Simple to unit test
Dynamic queries (2)
Comprehensive ORM
Primary Key generation (2)
Supports inherited objects (2)
Schema Creation
Existing schema
-
    -
  1. refers to whether it is necessary to write the persistence yourself (e.g as with JDBC) or - whether you can just persist by simple calls.
  2. -
  3. requires the developer to write this layer.
  4. -
-
- - + + +

Why JDO ?

+

+ 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. +

+
    +
  • If your datastore is RDBMS you can handle the persistence (and retrieval) of data yourself + using JDBC. Obviously with this route you have the burden of having to write the + persistence layer yourself. This gives much control, but also creates significant work, + both in writing the code but also in testing and maintenance.
  • +
  • You can use JDO, a standardised persistence API. With JDO you can develop + plain old java objects (POJOs) and persist them as they are transparently. This requires + very little work from the developer. It allows persistence to any type of datastore in + principle, being designed with flexibility and datastore agnositicity in mind. + This has been a standard since 2002 (JDO1), being upgraded in 2006 (JDO2) and + is in the process of being developed further (JDO2.1) by Apache JDO
  • +
  • You can use JPA, a standardised persistence API, and part of the EJB3 specification. This also allows you to + to develop plain old Java objects (POJOs) and persist them using a standardised API. It's specification + is not as mature or as feature rich as the JDO API, nor does it provide the flexibility + of using any type of datastore. This was released in 2006 (JPA1) to supercede EJB2. It really + only allows persistence to RDBMS datastores. If you want to persist to other datastores + you should consider JDO.
  • +
  • If you are stuck with using an EJB2.* architecture you could use Entity Beans. This + means that you hand off your objects to the EJB part of the J2EE server. This simplifies + things for the developer in some respect but places major restrictions in that your objects + have to be Entity Beans.
  • +
  • You can also use a proprietary persistence API (e.g Hibernates own API, TopLinks own API, iBatis, Castor etc). + The disadvantages of going this route are that you cannot easily swap to an alternative + implementation of the API if you hit problems with your software choice.
  • +
+

+ To give a guide, here are a few important consideration points when choosing a persistence layer for your application. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureJDBCJDOJPAEJB2Custom ORM
Standards-Driven
Choice of datastores
Support POJOs
Usable in J2SE
Usable in J2EE
Out of box implementation (1)
Simple to unit test
Dynamic queries (2)
Comprehensive ORM
Primary Key generation (2)
Supports inherited objects (2)
Schema Creation
Existing schema
+
    +
  1. refers to whether it is necessary to write the persistence yourself (e.g as with JDBC) or + whether you can just persist by simple calls.
  2. +
  3. requires the developer to write this layer.
  4. +
+
+ +