侦听和处理用户对业务对象改动的简易框架（下）

上篇地址：http://ldd600.iteye.com/blog/534039

从“侦听和处理用户对业务对象改动的简易框架（上）”中知道整个Framework的原理还是相当简单的，稍微值得注意的可能是下面几个方面。

Listener如何获取被改动的对象

TopLink会把所有改动过的对象都会被放在UnitOfWorkChangeSet中，因为在UnitOfWork提交的时候它需要将UnitOfWorkChangeSet中记下的改动提交到数据库。然后merge到session cache。所以所有改动从UnitOfWork中都是可以拿到的。

public class ActionLogPassiveAsyncListener extends AbstractActionLogAsyncListener {

    private ValueDistiller distiller;

 

    public void preCommitUnitOfWork(SessionEvent sessionevent) {

        log.debug("preCommitUnitOfWork begin.");

        UnitOfWork unitOfWork = (UnitOfWork) sessionevent.getSession();

 

        if (null == unitOfWork.getUnitOfWorkChangeSet()) {

         unitOfWork.setUnitOfWorkChangeSet((oracle.toplink.internal.sessions.UnitOfWorkChangeSet) unitOfWork

                    .getCurrentChanges());

        }

        UnitOfWorkChangeSet ucs = unitOfWork.getUnitOfWorkChangeSet();

        if (ucs != null && ucs.getAllChangeSets() != null) {

            Set finishedObjects = new HashSet();

            Map<Class<?>, List<ChangedPair>> changedPairs = new HashMap<Class<?>, List<ChangedPair>>();

 

            for (Enumeration objectChangeSetEnum = ucs.getAllChangeSets().keys(); objectChangeSetEnum

                    .hasMoreElements();) {

                ObjectChangeSet objectChangeSet = (ObjectChangeSet) objectChangeSetEnum.nextElement();

                if (objectChangeSet == null) {

                    continue;

                }

                Object clone = objectChangeSet.getUnitOfWorkClone();

                if (!finishedObjects.contains(clone)) {

                    for (Class focusClass : this.focusClasses) {

                        if ((includeSubclass ? focusClass.isAssignableFrom(clone.getClass())

                                : clone.getClass() == focusClass)

                                && (filter == null || (filter != null && !filter.isFiltered(clone, unitOfWork)))) {

                            finishedObjects.add(clone);

                            if (objectChangeSet.hasChanges()) {

                                List<ChangedPair> changedPairList = changedPairs.get(focusClass);

                                if (null == changedPairList) {

                                    changedPairList = new ArrayList<ChangedPair>();

                                    changedPairs.put(focusClass, changedPairList);

                                }

                                Object originalObject = this.distiller.getOriginObject(clone);

 

                                changedPairList.add(new ChangedPair(originalObject, clone));

 

                            }

 

                        }

                    }

                }

            }

            if (!changedPairs.isEmpty()) {

                try {

                    ChangedPairMap changedPairMap = this.assembleChangedPairMap(unitOfWork, changedPairs);

                    this.changedPairCache.set(changedPairMap);

                } catch (ActionLogException e) {

                    if (shouldBreakIfException) {

                        throw new ActionLogRuntimeException(e);

                    }

                }

            }

            log.debug("preCommitUnitOfWork end.");

        }

    }

}

 

异步状态下，ActionRecord要在Application事务提交之后生成

同步状态下，ActionRecord的生成可以Join Application的transaction，这样他们会一起成功或者失败。但是异步情况下，就会是不同的事务，两个事务之间的关系可能是有先后顺序或者互不相干。互不相干是不可能的，从业务意义上讲只有Application的改动确实生效之后ActionRecord才能生成，但是将ActionRecord放在Application事务提交成功之后生成或者提交，也会面临一个问题，就是application成功提交了，但ActionRecord的生成可能会失败。但要知道ActionRecord失败的几率远比Application提交失败的几率要小得多，application常常会因为乐观锁的问题而提交失败，但ActionRecord只可能因为DB Shutdown而丢失数据。失败后会做详细的备份，以便做恢复。那如何感知application事务是提交成功还是失败了呢？TopLink的SessionEventListener有四个有用的回调方法：PreCommit，PostCommit，PostRollback，PostRelease，用户事务提交的时候在提交之前会调用PreCommit方法，这时我们还可以从UnitOfWork中获取新老对象，我们会把老对象深clone一份出来，将他们存放在ThreadLocal中，而在PostCommit回调的实现中，我们会从ThreadLocal中取出新老对象完成ActionRecord的生成，而PostRollback就可以什么都不干了。但不管是提交成功还是提交失败Rlease方法都会被调用，UnitOfWork需要release，这里我们就会去清空ThreadLocal，以便内存即时的垃圾回收。这样说来即使是主动调用ActionAsyncService也会注册一个Listener，不同的是这个Listener不需要从UnitOfWork检测变化。

public class AbstractActionAsyncListener extends AbstractActionListener {

    protected ThreadLocal<ChangedPairMap> changedPairCache = new ThreadLocal<ChangedPairMap>();

   

    public void postCommitUnitOfWork(SessionEvent arg0) {

        ChangedPairMap changedPairMap = this.changedPairCache.get();

        if (changedPairMap != null) {

            if (!changedPairMap.isEmpty()) {

//异步生成ActionRecord

            }

        }

    }

 

    public void postReleaseUnitOfWork(SessionEvent arg0) {

        if (this.changedPairCache.get() != null) {

            this.clearResource();

        }

    }

 

    private void clearResource() {

        this.changedPairCache.set(null);

}

}

 

 

public class ActionActiveAsyncListener extends AbstractActionAsyncListener {

    private Map<Class<?>, List<ChangedPair>> changedPairs;

 

    public void preCommitUnitOfWork(SessionEvent sessionEvent) {

        UnitOfWork unitOfWork = (UnitOfWork) sessionEvent.getSession();

        try {

            ChangedPairMap changedPairMap = this.assembleChangedPairMap(unitOfWork, this.changedPairs);

            this.changedPairCache.set(changedPairMap);

        } catch (ActionLogException e) {

            log.error("Assemble ChangePairMap fails! ChangedPairs: " + changedPairs.toString(), e);

            if (shouldBreakIfException) {

                throw new ActionRuntimeException(e);

            }

        }

    }

}

 

 

ObjectCloner：

如果对象树的结构很庞大，深copy的性能代价不得不考虑。BeanUtils进行深copy的性能很差。5000个对象花了我20s。首先要说的是其实不需要所有对象引用都需要深copy，只有那些用户对关注的对象属性才需要深copy，clone的步骤大概如下：

l           对根对象进行浅copy

l           对用户关心的对象属性迭代的进行深copy

l           如果关心的对象属性是Collection，浅copy Collection中的每个对象并深copy对象中用户关注的对象属性

l           其实那些domain class，早在做ORM的时就确定下来了，所以所有domain对象反射metadata都可以事先确定，存在内存中，这样会大大提高性能，其实toplink也会把这些反射结构解析出来后缓存在内存中，直接利用toplink的clone逻辑就可以了。1000个对象深clone一把大约是120ms。