JDO快速入门 下

IQ>=0.5

3 透明的存储对开发人员来说，主要工作集中在业务逻辑的实现上，这就需要写一些控制类，来实现这些逻辑。这些控制类一般可以 XxxSession的方式来命名，表示面向某一类使用者的控制类，比如MemberSession，完成会员登录后的一些功能； AdminSession用于完成管理员登录后的一些功能。
在这些控制类中的一个方法中，只需要通过JDO规范的接口类（javax.jdo.*）来获取对前面的实体的访问，从而完成业务功能。一个典型的方法如下：
MemberSession的发表主题贴的方法：
public Topic postTopic(String title,String content, String forumId) {
       //业务逻辑过程开始
       javax.jdo.PersistenceManager pm = getPersistenceManagerFactory().getPersistenceManager();
       pm.currentTransaction().begin();
       //先生成一个主题，设置基本属性
       Topic topic = new Topic();
       topic.setTitle(title);
       topic.setContent(content);
       topic.setPostTime(new Date());
       //获取相关的论坛和当前登录的会员
       //下面用到的this.logonMemberId是本MemberSession对象生成时必须提供的会员标识。
       //本MemberSession对象一般是在登录的时候生成的。
       Forum forum = (Forum)pm.getObjectById(pm.newObjectIdInstance(Forum.class,forumId));
       Member author = (Member)pm.getObjectById(pm.newObjectIdInstance(Member.class, this.logonMemberId));
       //设置该主题的论坛和作者
        topic.setForum(forum);
        topic.setAuthor(author);
        //标记为需要存储
        pm.makePersistent(topic);
        //顺便更改论坛和作者的一些相关属性
        forum.setTopicCount(forum.getTopicCount()+1);
        author.setPostCount(author.getPostCount()+1);
        //业务逻辑过程完成
        pm.currentTransaction().commit();
        pm.close();
}
这样，这个方法就算写完了。我们可以看到，只要将与实体类相关的代码放在pm.currentTransaction()的开始和提交之间就可以了。
唯 一中间需要与JDO打交道的就是对新生成的对象（topic）需要调用一下pm.makePersistent()，但实际上在很多情况下，只要从pm中 取出的对象指向这个对象（比如：author.getPostTopics().add(topic)），就根本不需要这条语句（当然写上也没错），因为 pm会根据可达性（Reachability）的原则将当前已经在数据库中的对象能直接或间接指到的新生成的那些对象都存储起来。
以上的代码说明了我们不必对每个发生变化的对象调用更新函数，因为JDO的pm会自动跟踪这些变化，并将确实发生改变的对象同步到数据库。这就是“透明的存储”。
4 灵活的查询：JDOQL vs SQL
JDOQL是JDO中使用的查询语言，是对象式的查询语言，很象OQL，也很象EJBQL，但没有EJBQL那种只能静态存在的缺点。
对象式查询语言的优点有很多文章都有介绍，这里不再说明。只说明一点：JDOQL完全基于UML实体类图，不必理会具体数据库中的任何内容。
下面举一些例子，说明这种灵活性。
4.1 例：查找某作者发表过贴子的所有论坛
我们给出的参数只有作者的姓名，希望得到的是所有的他发表过主题或回复过主题的论坛。我们需要这样的JDOQL条件：首先查询的目标是Forum类，然后是JDOQL的过滤串
this == _topic.forum && (_topic.author.name == “” || _topic.contains(_reply) && _reply.author.name == “”)
然后，声明用到的变量：Topic _topic; Reply _reply;
再执行SQL即可。一般的JDO产品会将这个查询尽可能优化地翻译为：
select a. from FORUM a, TOPIC b, REPLY c, MEMBER d
where a.FORUM_ID = b. FORUM_ID and (b.MEMBER_ID = d. MEMBER_ID and d.NAME=’’ or b.TOPIC_ID = c. TOPIC_ID and c.MEMBER_ID = d.MEMBER_ID and d.NAME = ‘’)
从上面，我们可以看到，JDOQL无论在可读性还是可维护性上都远远好于SQL。我们还可以将作者姓名作为一个绑定参数，这样会更简单。
如果直接操作SQL的话会变得很麻烦，一方面要注意实体类中的属性名，一方面又要注意在数据库中的对应字段，因为多数情况下，两者的拼写由于各种因素（如数据库关键字冲突等）会是不一样的。
从这个例子扩展开去，我们可以进一步：
4.2 例：查找某作者发表过贴子的所有论坛中，总贴数大于100并且被作者收入自己的收藏夹的那些论坛
很简单，将过滤串这样写：
this == _topic.forum && (_topic.author == _author || _topic.contains(_reply) && _reply.author == _author) && _author.name == ‘’ && postCount > 100 && _author.favoriteForums.contains(this)
这一次多了一个用到的变量：Member _author。其底层的SQL大家可以自己去模拟。
5 长字符串
我们经常会遇到用户输入的某个信息文字串超出了规定的数据字段的大小，导致很麻烦的处理，尤其是一些没有必要限制长度的字符串，比如一篇主题文章的内容，有可能几万字，这迫使我们将其分作很多子记录，每条子记录中放一部分。所有这些，都使我们的代码量加大，维护量加大。
现在有了JDO，我们的代码就简单多了，我们可能尽量利用JDO提供的透明存储功能，通过一些简单的工具类实现：原理是将其分割为字符串子串。
package jdo_util;
import java.util.*;
public class StringHelper {
    public static List setLongString(String value) {
        if(value == null) return null;
        int len = value.length();
        int count = (len+partSize-1)/partSize;
        List list = new ArrayList(count);
        for(int i = 0; i //字符串片断的大小。针对不同的数据库可以不同，如Oracle用2000
}
有了这个类以后，我们只需要将Topic.content的类型换成List，而其访问器的接口不变，仍是String，只是内容变一下：（并在JDO描述符中指明该List的元素类型是String）
public class Topic {
    …
    List content; //原先是String类型
    …
    public String getContent() {
        return StringHelper.getLongString(content);
    }
    public void setContent(String value) {
        content = StringHelper.setLongString(value);
    }
}
这样，就解决了长字符串的问题，而其它相关的代码完全不需要改，这就支持了无限长的主题内容。
最后，唯一的缺陷是对内容进行关键字查询的时候需要将
content.startsWith(‘%’)
变为
content.contains(s) && s.startsWith(‘%’)
并且，可能查询结果不太准（比如正好跨越两个子串部分）。庆幸的是，一般这种对很长的字符串字段的查询需求不是太多。
需要说明的是，采用传统的SQL同样也会需要对拆分的字符串进行额外的查询，并具有同样的缺点。
另外，这个功能需要JDO产品支持规范中的一个可选选项：javax.jdo.option.List，主要的几个JDO产品都支持。比如KodoJDO和JDOGenie。
6 资源回收：pm.close()
我们采用传统SQL写代码时，最危险的就是资源释放问题，这在基于WEB的应用中尤其重要。因为与JDBC相关的资源不是在Java虚拟机中分配的，而是在系统底层分配的，Java的垃圾回收机制鞭长莫及，导致系统内存慢慢耗光而死机。
在JDBC中需要主动释放的资源有：Connection、Statement、PreparedStatement、ResultSet，在每个对这些类型的变量赋值的时候，都必须将先前的资源释放掉。无疑是一件繁琐而又容易被忽略的事情。
在JDO 中，事情变得简单多了，所有的资源在pm.close()的时候会自动释放（除非JDO产品增加了一些对PreparedStatement和 ResultSet的Cache），这是JDO规范的要求。因此，只要我们记住在对实体类处理完毕时调用pm.close()就行了。比如下面的代码：
PersistenceManager pm = null
try {
    pm = getPersistenceManagerFactory().getPersistenceManager();
    //做一些数据类的处理工作
} finally{
    pm.close();
}
有些人可能就是不喜欢调用它，觉得烦，因为每次要用时都要打开一个PM，而用完时都要关闭，如果JDO产品没有PM连接池的话，性能可能受到影响。这样，我们可以利用下面的继承java.lang.ThreadLocal的工具类完成这一点：
public class PersistenceManagerRetriever extends ThreadLocal {
    /**
     * 根据配置信息初始化一个PersistenceManager获取器
     * @param p
     */
    public PersistenceManagerRetriever(java.util.Properties p) {
        pmf = JDOHelper.getPersistenceManagerFactory(p);
    }
    /**
     * 获取相关的PersistenceManagerFactory
     * @return 一个PersistenceManagerFactory对象
     */
    public PersistenceManagerFactory pmf() {
        return pmf;
    }
    /**
     * 获取一个与当前线程相关的PersistenceManager
     * @return 一个PersistenceManager对象
     */
    public PersistenceManager pm() {
        return (PersistenceManager)get();
    }
    /**
     * 释放所有与本线程相关的JDO资源
     */
    public void cleanup() {
        PersistenceManager pm = pm();
        if(pm == null) return;
        try {
            if(!pm.isClosed()) {
                Transaction ts = pm.currentTransaction();
                if(ts.isActive()) {
                    log.warn("发现一个未完成的Transaction ["+pmf.getConnectionURL()+"]！"+ts);
                    ts.rollback();
                }
                pm.close();
            }
        } catch(Exception ex) {
            log.error("释放JDO资源时出错："+ex,ex);
        } finally {
            set(null);
        }
    }
    public Object get() {
        PersistenceManager pm = (PersistenceManager)super.get();
        if(pm == null || pm.isClosed()) {
            pm = pmf.getPersistenceManager();
            set(pm);
            if(log.isDebugEnabled()) log.debug("retrieved new PM: "+pm);
        }
        return pm;
    }
    public static final Logger log = Logger.getLogger(PersistenceManagerRetriever.class);
    private PersistenceManagerFactory pmf;
}
这样，只要在一个线程中（比如一次页面请求），在所有的需要PM的地方，都只需直接调用
persistenceManagerRetriever.pm();
即可，并且，只在最后用完后才调用一次persistenceManagerRetriever.cleanup()以关闭它。
这个persistenceManagerRetriever可以在某个系统类的初始化代码中加入：
PersistenceManagerRetriever persistenceManagerRetriever = new PersistenceManagerRetriever(properties);
而关闭当前线程相关的PM的语句（persistenceManagerRetriever.cleanup()）可以配置一个JspFilter来完成它，比如：
    public static class JspFilter implements javax.servlet.Filter {
        public void doFilter(
            javax.servlet.ServletRequest request,
            javax.servlet.ServletResponse response,
            javax.servlet.FilterChain chain)
        throws javax.servlet.ServletException,java.io.IOException {
            try {
                chain.doFilter(request,response);
            } finally {
                if(pmRetriever != null) pmRetriever.cleanup();
            }
        }
        public void init(javax.servlet.FilterConfig filterConfig) throws javax.servlet.ServletException {}
        public javax.servlet.FilterConfig getFilterConfig() { return null; }
        public void setFilterConfig(javax.servlet.FilterConfig fc) {}
        public void destroy() {}
    }
然后我们将其配置在WebApp的描述符中：
        jdo_JspFilter
        …xxx.jdo_util.JspFilter
        jdo_JspFilter
        *.jsp
这样，我们在JSP中的代码更简单：
…
persistenceManagerRetriever.pm().currentTransaction().begin();
//调用一些处理业务逻辑的XxxSession.someMethodThatUsesPM()方法，这些方法中直接用persistenceManagerRetriever.pm()来取得PM。
persistenceManagerRetriever.pm().currentTransaction().commit();
不用处理异常，JspFilter自会处理。
7 ID与对象模型
对 象标识字段，实际上只是一个数据库范畴的字段，在对象模型中实际上是不需要这些属性的。也就是说，在Java应用中，一个对象的标识就是在内存中的地址， 不并是这个对象本身的属性，因为根据这个内存地址就可以唯一地确定这个对象。比如一个编辑矢量地图的Java程序，从文件中读入各个地图元素（对象）后， 这些对象就有了一个唯一的内存地址，所以不需要给每个对象加一个类似“ID”之类的属性并写入文件。
JDO也采用了这样的概念，ID独立于对象之外，并不属于对象的一部分。前面的论坛实体类图中我们可以看到，每个类中都没有类似“id”之类的属性。那么，JDO怎样控制与数据库中的主键的对应呢？这就是两个常用的工具类方法：
Object PersistenceManager.getObjectId(Object obj)
Object PersistenceManager.getObjectById(Object obj, boolean validate)
这样，可以随时获得某个实体对象的ID，也可以在任何时候通过一个ID找出该对象。第一个方法还可以用javax.jdo.JDOHelper.getObjectId()代替。
JDO 规范建议的模式中，这些ID都是由JDO产品自动生成的，项目应用中只在需要传递对象的引用的时候才使用，比如在两个页面间传送。并且，这些ID类都是可 以与String互转的，这就方便了JSP间的传递。这种由JDO产品来控制的ID叫做datastore identity，在数据表中的字段名一般是“JDO_ID”。
如果实在是想自己控制对象在数据库中的ID，JDO也提供用户自定义的ID，这 时，该ID作为对象的一个属性存在，可以是任何类型，int, Date, String, 或其它自定义的复合类型（如两个属性合起来作ID）。这种类型的ID叫做application identity。
就个人而言，我建议在新的项目中采用datastore identity，这样可省下很多时间。而在实体类中，也可以写一些替代的方法来保持与application identity保持兼容，如：
public class SomePersistentClass {
       …
       public String getId() {
            return JDOHelper.getObjectById(this).toString();
       }
       public static SomePersistentClass getById(String id) {
           PersistenceManager pm = persistenceManagerRetriever.pm();
           return pm.getObjectById(pm.newObjectIdInstance(SomePersistentClass.class, id));
       }
}
这种方式对两种类型的ID都有效。注意，这个类本身有这两个方法，但并没有一个ID属性。
8 缓冲与Optimistic Transaction
缓冲是JDO中的一个亮点。虽然JDO规范并没有严格要求一个JDO产品必须实现什么样的缓冲，但几乎每一个JDO产品，尤其是商业化产品，都有比较完善的缓冲体系，这个体系是不同的JDO产品相互竞争的重点之一。
主要的JDO产品包含下列缓冲：
1. PM连接池。对PersistenceManager进行缓冲，类似JDBC连接池，在调用pm.close()的时候并不关闭它，而是等待下一次调用或超时。
2. PreparedStatement缓冲。如果JDO底层发现一个JDOQL语句与前面用过的某句相同，则不会重新分析并生成一个新的 PreparedStatement，而是采用缓冲池中的已有的语句。对PreparedStatement的缓冲也是JDBC3.0规范中的一项功能。 而JDO底层发现如果配置的是符合JDBC3.0规范的驱动时，会采用驱动的缓冲，否则采用自己的缓冲。
3. ResultSet缓冲。这种缓冲的实现的JDO产品不多，目前好象只有KodoJDO 2.5.0 beta实现了。其机制是如果第二次请求执行同样JDOQL语句、同样参数的查询时，JDO底层从上一次执行结果中取出该集合，直接返回，大大增强性能。 不过比较耗资源，因为是采用JDBC2.0中的ScrollableResultSet实现。
一般我们在对数据库进行更新操作时，都会对 数据库进行锁定操作，设定不同的隔离级别，可以完成不同程度的锁定，比如锁记录、锁字段、锁表、锁库等等。而JDO中可以在具体JDO产品的厂商扩展 （Vendor Extension）标记中设定。另外，JDO规范还提供了一种对数据库完全没有锁定的方式： javax.jdo.option.OptimisticTransaction，它是一项可选选项，也就是说，并不强制JDO厂商实现它，不过主要的几 个厂商的JDO产品都实现了这个功能。
OptimisticTransaction的机制原理是：在每个对象的数据库记录中增加一个交易控制字 段，然后所有的对象更改在Java虚拟机的内存中完成，当提交的时候，会检查每个被改过的对象的在从数据库中取出后是否被其它外部程序改过，这就是通过这 个控制字段完成的。一般这个字段的实现方式有以下几种：
1. 存放最近一次更改的时间，字段名多取作“JDO_LAST_UPDATE_TIME”
2. 存放历史上被更改过的次数，字段名多取作“JDO_VERSION”
在OptimisticTransaction 的一次Transaction中，JDO底层不会对数据库进行锁定，这就保证了时间跨度较长的transaction不会影响其它线程（请求）的执行，只 是如果更新操作比较多，访问量又比较大的话，Transaction提交失败的的几率也会相应变大。
9 JDBC2.0和JDBC3.0JDO只是一种对象级的包装，是建立在JDBC的基础上的，两者不能相互替代。实际上，JDBC的规范从1.0到2.0，再到3.0，一直在做功能和性能方面的改进。
JDO 产品当然不会放过这些，一般的JDO产品，会检测底层配置的JDBC驱动是符合哪个规范，并会尽量采用驱动本身的功能来实现具体的操作。对代码开发人员来 说，我们大多数情况下只能掌握JDBC1.0的操作，和少量的2.0的操作，只有一些很精通JDBC的高手才会用到JDBC3.0中的高级功能。因此，采 用JDO也可以帮助我们在不了解JDBC3.0规范的情况下提高性能和效率。
换句话说，JDBC技术本身就是一件很复杂的东西，要想优化性能的 话，很多JDBC技术和数据库技术是需要使用的，比如inner join, left/right outer join, Batch update，等等。这些对开发人员的技术要求很高，一方面要精确理解每种技术的应用范围和实际使用的注意事项，另一方面代码也会比较复杂。因此，既然有 众多的有经验的JDO厂商在做这些事情，我们又何必再花功夫呢？

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/25869/showart_420502.html