在這個架構中，所有的JPA操作用於替代數據網格，JPA操作通常會使用SQL用於數據庫。這包括所有的 查詢和所有的更新。根本上，我們用數據網格完全的取代數據庫。伴隨著JP QL轉換支持，盡管數據存儲 是專門在中間層操作，我們仍然可以繼續使用JPA為我們設計API。對於系統而言，不需要長期持久的存儲 ，這是理想狀態。如果要求更多的存貯或者查詢性能，你可以簡單的增加服務器到網格。
數據庫——依靠數據網格
即使所有的查詢和更新執行都朝著不利於數據網格的方向發展，它仍然有可能融入到一個持久存儲器 數據庫。在這個構架當中，網格負責傳遞網格中的操作性能到數據庫。比如說，輸入一個對象到網格將會 引起數據庫的INSERT操作。這個架構的優勢是數據仍然可以頻繁使用，而更新會返回到數據庫，並且可以 報告目的等等。理想的情況下，網格操作不會同步傳遞到數據庫，這樣的話會明顯地減弱生產力。異步書 寫更新到數據庫可以保持網格的靈敏性，並且支持持久性存儲的要求。
混合以及匹配——多種結構
迄今為止，我們把數據網格作為JPA的存儲器對待，並且認為JPA是數據網格上層的API標准。這個架構 之間的不同點實在不明顯。對於新對象來說，歸結到配置上面，要看JPA是否是首先書寫在數據庫上，然 後寫入數據網格，或者是否它僅僅是寫在網格上面。處理更新以及刪除操作時候的邏輯與上面相同。就像 我們看到的，查詢操作也與此類似。如果我們可以設置如何在一個實體對實體的基礎上讀取、輸入、查詢 ，我們就可以混合這些架構。考慮存儲器與應用程序之間的往來。在這樣一個應用程序中，你可以得到“ 持久的”實體。但是你也會得到短暫的實體。為了一個持久的實體，實體級別的架構可以使得JPA使用數 據網格作為存儲器。
按照數據網格修改JPA
如果順利的話，把JPA與數據網格相結合是很有可能的，並且可以通過提供快速存取來提升系統的生產 力，從而在中間層進行數據管理。但是他們也為JPA應用程序提供測量標准，與普通方法相比它的可測量 性更顯著。
傳統意義上，提高JPA應用程序的應用率需要提高應用群集上服務器的數量，使用下載平衡來均勻的分 布工作。但是當你提高群集的大小，發現這個群集大小是受你限制的，限制它可以存儲的內容而不需要引 進進程之間的通道和連接。更新然後共享數據可以傳遞到所有的群集服務器，來確定JPA存儲器不包含陳 舊的數據。對於一個伴隨著N個服務器的群集來說這意味著每一個更新將會產生N-1個信息。當你增加群集 中服務器的數量，每一個服務器處理一個單一的同步更新的花費依據(N-1)2這樣的速率增加，因為任何一 個更新發生，每一個服務器都必須與其它所有的服務器通信。更糟糕的是，伴隨著群集的增長，每一個服 務器都不得不花費大量的可用處理時間來解決新到達的更新信息。那些非線性的通信以及更新處理成本意 味著群集JPA應用程序的傳統方法利用存儲器可以很好的工作，他們受限於小到中型號的群集。
通過擁有一個可共享副本，數據網格能夠解決通信上的問題，這個副本來自所有服務器的易存取的對 象。一個更新操作是不需要依賴於將信息傳遞到所有服務器的，因為在下次他們需要更新對象的時候，是 可以跟上變化的。在一個數據網格中，伴隨著可升級的點對點通信架構(即不需要中心信息就可以打破瓶 頸)，一個更新是依賴於到服務器的通信的，這是個存儲對象的服務器，或者是一個存儲備份的服務器。 這種情況下，存取每個服務器單一的同步更新上的通信花費是可以用線性函數C(N)描述的，C是副本(基本 的以及備份的)數量的持續反映。這種線性更新的花費意味著通過使用數據網格來擴展群集有可能實現評 測JPA應用程序，以及達到更高的生產力。
質疑
當然，網格上的JPA從來都不缺乏挑戰。第一條就是開發者對於對象關系映射非常的熟悉，JPA無疑會 被認為緩存疲勞。這是存儲器帶來的最常見的問題。緩存疲勞有兩個原因：第三方更新數據庫，以及JPA 應用程序運行在其他服務器群集上實現更新操作。處理第三方更新問題與處理處理數據網格沒有什麼不同 ，大多數JPA執行提供一系列的技術來處理這些問題，包括驅逐規則，查詢恢復原則，以及針對極易變更 的數據，廢除存儲的能力。這已經是一個陳舊的話題，數據網格不會特別的復雜化。
就像之前討論的那樣，緩存疲勞影響更新，使得在其他群集服務器中使用傳統的解決方法，也就是通 過信息解決，盡管它有自己的限制。再高處理速率的系統中，信息頂層是非常重要的，JPA應用程序趨向 於把緩存的使用降至最低，依賴數據庫來確定他們是不是將數據更新。具有諷刺意義的是，處理速率提高 以及存儲器價值的提高經常是有缺陷的，因為維護存儲器持續運作的花費實在是太高了。實際運用數據網 格來刪除信息以及更新處理情況意味著高速處理系統可以利於存儲器達到甚至是超越生產力，而不需要管 理緩存疲勞。
查詢是另一個挑戰。JPA界定了JP QL的多種用途，在很多方面與SQL是相似的，包括很多相同的小細節 。JP QL的目標是提供一個以對象為基礎的查詢語言，可以簡單的轉換為執行在關系數據庫上的SQL。當然 ，數據網格不是關系數據庫，每一個數據網格擁有自己的查詢框架。JP QL可以被轉化的范圍以及在特定 網格上面的執行都要依靠網格查詢框架的性能。
另一個挑戰來自關系對象。JPA支持很多的關系類型，除了嵌入式對象。通過數據網格產品，關系對象 的支持呈現各種不同的形式，每一個都有細微的差別。焦點包括：哪一種類型的關系對象可以支持;對象 之間是否可以通過網格關聯或者更多的是駐扎在一點;在關系對象中哪一種查詢操作是被支持的。最後一 個問題的答案明顯對於哪一種JP QL查詢可以執行有重大影響。
這個列表很明顯是不全面的，但是它提煉了對PA/data網格整合有影響的問題中的精華部分。
結論
數據網格不是關系數據庫，所以我們不能期望JPA與數據網格之間有一個完美的契合。但是，即便有很 多限制，網格上面的JPA也是令人激動的技術，它提供了一種方法：進化JPA應用程序使其站在槓桿的另一 端，撬動數據網格能夠創建可升級的高速率系統。
