了解Hibernate的FlushMode.NEVER

　　在Tim的项目中存在着一个十分典型的case(我也不大了解生物，这不能怪我):在实验中利用PCR Primers对遗传基因(genes)和DNA中的核苷酸序列(exons)，这里的PCR Primers是在PCR处理过程中用于检测DNA片段的物质，对不起大家，本人对生物学词汇实在无能为力。检测匹配过程大致分为以下7步:

　　1.发现本次实验中所有exons(个数在5000个以上);

　　2.查询本次实验所有已经排序的PCR Primers;

　　3.查询本次实验所有待排序的PCR Primers;

　　4.得到与exons对应的Primers找出那些无需转换的部分;

　　5.在系统中为无需转换的区域查询所有可能的PCR Primers;

　　6.测试每个primer找出最佳exons匹配者(Primer);

　　7.保存找出的Primer。

　　不用担心，步骤细节不大明白也不会影响后面的理解。

　　由于domain model极其海量，在第4步我们可能在一个session中排序20000-30000个对象。而在5、6步的查询将带来0-20个附加对象。有趣之处在于当执行第7步将对象save到数据库时，没有一个前面装载的对象被修改过。整个实验的目的就是仅仅获得这0-20个对象。

　　在回顾了Tim的生物学场景之后，让我们重新回到FlushMode.NEVER的讨论上来吧。你可能认为既然直到最后一步都没有修改或是持久化任何东西，那么改变flush模式将收效甚微。当然这是不正确的未参透实质的理解。实际上，在上面流程的起始设置Never这个flush模式、在流程终点手动flush将节省一半的run time，请注意这里仅提到了run time而没有将内存、IO计算在内。

　　三、这个杀手不太“冷”

　　图片来自于电影《黑衣人》