JDO是Java對象持久化的新的規范。JDO經SunJava Community Process認定。
一、歷史
JDO是對象持久化工作的綜合成果，試圖提供一個對象持久化的完全版本。JDO同時繼承于ODMG（對象數據管理小組，標準化對象數據庫的一個獨立委員會）和對象關系映射工具提供商。
JSR #000012 approved in July 1999
1999-8組建的專家小組：包括Sun、Apple、BEA、IBM、Oracle、SAP、WebGain等
2000-5 完成公開評論草案
2000-6 在JavaOne上引入
2001-3 最終草案0.93
2001-5 最終草案0.96公布
2001-6 在JavaOne上啟動
2001-11 最終草案0.98
二、目標
定義對象級的持久化。
完全支持對象模型，包括引用、集合、接口、繼承
完全透明持久化：這使得業務對象完全獨立于任何數據庫技術，這使用了一個字節碼增強機制（a byte-code enhancement mechanism）。
縮短開發周期（不再需要映射）
在開發小組中清晰地劃分業務人員和數據庫人員。
通用持久性
? JDBC限于RDBMS，JDO潛在地可以處理任何類型的數據源，包括RDBMS，ODBMS，TP監控處理，ASCII無格式文件，xml文件，properties文件，大機上的Cobol數據庫，等
? JDO是面向大型信息系統的一個完全的解決方案，在這樣的系統中，信息存儲于多種異質數據源
涵蓋J2EE、J2SE、J2ME的廣泛實現
強壯的事務模型
同時支持C/S和多層體系結構
三、體系
JDO 包
PersistentCapable：擁有持久實例的類必須實現這個接口。管理對象生命周期。
PersistenceManager ：代表了到數據源的連接。一個應用可以打開一個或多個PersistenceManagers。
PersistenceManagerFactory：允許從數據源中得到一個PersistenceManager的實例，這個工廠也可以作為一個連接池。
Transaction：允許界定事務
Query ：允許明確地聲明性地使用JDO查詢語言從數據源中獲取數據。NB：也可以通過引用之間的基本的定位，隱含地、透明地從數據源中獲取對象。
InstanceCallback：在數據庫操作中（比如before/after read, before/after write，等），定義一些鉤子，以做特殊處理（像暫時屬性的初始化）。
JDOException：JDO操作中拋出的例外。
JDO也定義了幫助類，對象標識（由應用或數據源管理）
JDO實現可以支持或不支持兼容的PersistenceManager（當PersistenceManager是兼容的時，你可以得到存儲于不同數據庫的對象引用）。
NB：在JDO的第一個發布版本中，并沒有嚴格地定義鎖和鎖策略。
JDO對象模型
JDO對象模型基本上是Java的對象模型，包括所有的基本類型，引用，集合和事件接口。
除了系統定義類（system-defined classes），支持所有的字段類型（包括簡單型、可變和不變的對象類型〔immutable and mutable object types〕、用戶定義類、數組、集合、接口）。
支持所有的成員變量修飾符（private, public, protected, static, transient, abstract, final, synchronized, volatile）
除了對象狀態依賴于不可訪問的或遠程對象，即繼承于java.net.SocketImpl、本地方法等，所有的用戶定義類都可以是PersistentCapable。
JDO對象生命周期
為了能夠在數據源中訪問、存儲對象，應用必須首先得到一個或幾個數據源的連接。一個JDO PersistenceManager對象就代表了這樣一個連接。它可以通過PersistenceManagerFactory類得到。持久化對象必須是實現了PersistentCapable接口的類的實例。這樣的類可能同時擁有持久化的或臨時的（transient）實例。
為了使一個實例持久化，編程者必須調用PersistentManager的makePersistent方法。通知JDO對象為持久化或臨時的很重要，即使它們可以從JDO的行為中得到它是臨時的，比如事務管理和對象標識。對象標識可以由應用管理，或者由數據源代理（這大多是在使用ODBMS實例時，因為概念ObjectID本身就是ODMG模型的一部分）。
JDO支持一種持久化模型，這這種模型中持久性自動傳播到引用的對象。這種機制經常稱為“延伸持久（persistence by reachability）”或者“傳遞持久（transitive persistence）”。這意味著一旦一個已經持久化的對象引用了一個臨時對象，這個臨時對象自動變成持久化的。對于JDBC編程者，這個模型可能很奇怪，但是他們會發現這是大多數情況下編程者希望從持久化框架中得到的支持。
例子：
pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance()); pmf.setConnectionDriverName("versant"); pmf.setConnectionURL(dbName); pm = pmf.getPersistenceManager(); tx = pm.currentTransaction(); tx.begin(); Provider aProvider = new Provider("LIBeLIS"); pm.makerPersistent(aProvider); // aProvider now persists Address anAddress = new Address("25 rue Paul Barruel", "France", "Paris"); aProvider.address = anAddress ; // anAddress now persists tx.commit(); pm.close();
對象或者通過明確的JDO查詢結果從內存中得到，或者通過標準的Java對象之間的導航（navigation）得到。
最后這個機制很強大，你可以把持久對象想像為在JVM堆中的一個特殊的部分，我們稱之為“客戶端緩存（client cache）”。每次當你企圖從一個對象導航到另一個時，如果這個對象尚不在內存中，JDO會自動從數據源中獲取，并把它放在緩存中。
例子
假設aProvider對象已經裝載到內存，但是它的Address對象還沒有。當你寫下如下代碼時：
System.out.println(aProvider.address.city);
Address對象會自動裝載。緩存管理自動鏈接到事務邊界（transaction boundaries），這意味著緩存將在事務結束是刷新，所有的實體都標示為無效的。下次對象訪問它們的狀態時，自動地、透明地從數據源中再次裝載。
例子
pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance()); pmf.setConnectionDriverName("versant"); pmf.setConnectionURL(dbName); pm = pmf.getPersistenceManager(); tx = pm.currentTransaction(); tx.begin(); Provider aProvider = new Provider("LIBeLIS"); pm.makerPersistent(aProvider); Address anAddress = new Address("25 rue Paul Barruel", "France", "Paris"); aProvider.address = anAddress ; tx.commit(); // objects are stored into the data source, client cache is discarded, references are invalid tx.begin(); System.out.println(aProvider); // aProvider is refreshed from the data source tx.commit(); pm.close();
每次你修改了一個對象，它在JDO緩存中對應的實體將被標示為“臟（dirty）”。
例子
tx.begin(); aProvider.address = aNewAdr; // aProvider is marked as dirty tx.commit(); // aProvider will updated in the data source
在事務的結束，PersistentManager 將把所有標示為“臟”的JDO對象（臟對象）更新到數據源中。
JDO緩存中的每一個對象都有自己的狀態（實際上它們都和一個StateManager對象相關聯）。并且JDO規范規定了一大堆狀態和它們之間的過渡。如果感興趣，請參照JDO規范了解詳細。
NB：這些狀態一般是JDO提供商關心的，而不是JDO編程者。
開發周期
為了達到上面提到的完全透明的持久化，JDO定義了一個稱為“增強（Enhancement）”的字節碼工具機制（byte-code instrumentation mechanism）。它的思想是從業務類中剔除所有的顯式的數據庫依賴代碼。和已存在的或新的數據源的映射通過外部的元數據（metadata）XML文件定義。
JDO增強器讀取編譯的java文件（.class文件），并且應用元數據文件中定義的持久化規則。例示如下：
[[The No.1 Picture.]]
增強會添加到元數據文件描述的類的字節碼中：
• 實現PersistentCapable接口的聲明
• 該接口中聲明的方法的字節碼必須被實現
• 當修改了一個屬性后該對象標示為“臟”的代碼
• 需要時從數據源中獲取對象的代碼
• 根據元數據文件中指定的從數據源中的原始數據（raw data）到Java對象映射的代碼
NB：在專家小組中，是否要把增強列入JDO規范曾經激烈爭論過。一些專家認為開發者可能會被增強技術嚇倒。不熟悉這個技術的開發者會驚訝于字節碼增強，這是一個事實。但是增強是這樣一種通用、強大的開發技術，可以在很多案例中有效地使用。開始時，每當開發者遇到一個Bug時，可能會責難增強器。我們強烈推薦增強器的“新手”仔細地看一下BCEL網站（由Source Forge開源社區提供）。在那兒，你能看到許多關于字節碼增強的有用信息和工具。這種機制的熟手可以在他們的Java接口中成功地使用。所有的熟手都表現出了興趣。
在兩層（Client/Server）結構中整合
在傳統的Client/Server體系中，JDO應用需要使用由JDO實現提供的PersistenceManagers把它自己連接到一個或多個數據源。
[[The No.2 Picture.]]
臨時對象可以持有持久對象的引用。持久對象可以持有分布在多個PersistenceManagers中的持久對象的引用。但是這不是一個