首要特性是断开或分离操作模式――在这种模式中，用户应用程序连接到数据库并从中取回数据后立刻释放连接。数据作为相关的记录集被应用程序查看――POJO图形或DataGraph――看您喜好哪种术语了。数据可以在远程进程中修改，而不需要对数据库的原始数据建立活动连接。稍后，当重新建立数据库连接时，这些修改可以合并到持久性数据中。这种断开操作模式对可伸缩性非常关键，例如10000个活动用户可以同时操作包含十个数据库连接的连接池。这种应用程序使用模式同样节省了大量的金钱，因为随着连接数量的增加，数据库安装开销将呈指数级增长。JAP支持这种断开操作模式，当持久性存储上下文关闭或事务提交后，取回的POJO实例将断开连接，并且可以远程修改断开的对象图并稍后合并到不同的持久性存储上下文中。另一方面，SDO定义了ChangeSummary概念，用于跟踪断开的DataGraph中的改动。因此，JPA实现自然可以使用ChangeSummary内容将改动有效地并入到数据库中。
JAP和SDO自然结合的另一点是：它们都使用取回的数据作为连接对象图。JPA目前还没有充分开发定义断开数据图的潜力，但是OpenJPA或Kodo支持一种名为FetchPlan的强大扩展――来自于JDO规范的贡献，该规范良好定义了这一概念，即指定从数据库取回对象闭包的哪一部分。这种控制非常重要，因为完整的实例闭包通常就是整个数据库。另一方面，SDO DataGraph定义了一种经过配置的闭包，即所谓的根DataObject。
使用JPA持久性存储SDO的关键挑战是什么？
需要解决的关键分歧是类型系统。JPA是针对严格类型的POJO设计的。JPA实现管理的对象实例是由Java类静态定义的，并由Java编译器进行编译。JPA（及其前身JDO）的美妙之处在于：这些实现能够在不产生干扰的情况下截取对持久性实例的改变（状态和/或关系）。对象仍然保持POJO特性，但JPA运行时可以知道用户应用程序何时会对持久性对象调用setter方法以修改其状态，或何时调用要求从数据库取回更多日期（通常称为Lazy Loading）的getter方法。实际的实现会根据截取改动的方式而有所变化――例如――OpenJPA或Kodo取决于增强――该过程将修改编译后的持久性Java类的字节码，而其他实现可能会使用不同的机制，例如代理原始实体。无论哪种情况，都需要对实现作出较大的改动，以脱离其基本假设。例如，存在编译后表示持久性数据的Java类。
另一方面，SDO倾向于松散类型的对象。SDO可以使用名称和年龄表示一个Person对象，而不需要定义一个Person.java类。Person的定义可存在于一个XML模式文档中，或者甚至可以通过编程的方式创建。
那么如何使用JPA存储一个Person DataObject而不用编写Person.java类呢？理论上讲，JPA怎么能采用不是强类型的数据表示呢？
类型转换系统仅仅是开始。还有很多问题要解决：
如何定义实例的身份？
如何定义到数据库模式的映射？
如何使用Java表示SDO类型之间的关系？
如何将断开的DataGraph的改动转换为Java实例的更新？
如何放宽JPA限制以使用松散类型数据？
为了不被答案不是特别明显的问题混淆，我决定逐步执行一些步骤。因此我尝试解决几个简单场景或用例。
用例：通过JPA API将SDO Types/DataObjetcs转化为持久性数据
文章来源于领测软件测试网 https://www.ltesting.net/
