當transaction scope persistence context或extended persistence context結束之後，實體的實例就會不受托管而處於游離狀態。游離實體的一個值得注意的特征是，它可以被序列化並通過網絡發送給遠程客戶端。客戶端可以修改這些經過序列化的對象實例，並將它們發送回服務器，服務器再將客戶端的修改重新合並到數據庫中。
這與EJB 2.1的實體模型有很大的不同。在EJB 2.1中，實體是始終受容器管理的，使用entity bean的應用程序總要帶一個指向entity bean的代理(譯注：proxy，即遠程接口或本地接口);而在EJB 3.0中，你是直接與普通Java類的具體實例打交道的。對於EJB 2.1的開發人員而言，上述做法乍一看會覺得有些不適應，因為他們已經習慣了容器來為實體打點一切。不過，一旦你熟悉了新的EJB 3.0實體模型，就會發現，你的應用程序代碼將大幅縮減，並且更易於管理。
EJB 2.1的代碼中時常使用Value Object模式(也被稱為Data Transfer Objects)。該模式的主要思想是：讓entity bean暴露一個方法，該方法將bean的全部狀態復制到一個對象中，此對象可以被序列化到遠程客戶端(比如Swing應用程序)，以供遠程客戶端訪問。
// EJB 2.1 entity bean 類
public class CustomerBean implements javax.ejb.EntityBean {
CustomerValueObject getCustomerVO() {
return new CustomerValueObject(getFirstName(), getLastName(),
getStreet(), getCity(), getState, getZip());
}
}
在客戶端對entity bean進行遠程方法調用需要較大的系統開銷。如果客戶端必須通過調用getFirstName()，getLastName()等一系列方法才能獲得用於顯示的客戶相關信息，那麼性能將變得不堪重負。這便是Value Object模式的由來。而EJB 3.0中，由於持久對象在脫離persistence context之後將自動變成值對象，因此也就沒必要再使用該模式了。
