深入iBatis的Cache[转载自javaeye-NetBus 的心得体会]
深入iBatis的Cache[转载自javaeye---NetBus 的心得体会]关键字: ibatis cachecachemodel font idl
深入iBatis的Cache[转载自javaeye---NetBus 的心得体会]
关键字: ibatis cache
<cachemodel< font=""> id="lruCache" type="LRU" serialize="true" readOnly="false"> <property< font=""> name="reference-type" value="WEAK"/> <flushonexecute< font=""> statement="insertAccount"/> <flushonexecute< font=""> statement="updateAccount"/> <flushonexecute< font=""> statement="deleteAccountById"/> </cachemodel> <select< font=""> id="selectAccountById" parameterClass="int" resultClass="Account" cacheModel="lruCache"> select ACC_ID as id, ACC_FIRST_NAME as firstName, ACC_LAST_NAME as lastName, ACC_EMAIL as emailAddress from ACCOUNT where ACC_ID = #id# <update< font=""> id="updateAccount" parameterClass="Account"> update ACCOUNT set ACC_FIRST_NAME=#firstName# , ACC_LAST_NAME = #lastName# , ACC_EMAIL =#emailAddress# where ACC_ID = #id# </update> <cachemodelid="lruCache" type="LRU" serialize="true" readonly="false"><property name="reference-type" value="WEAK"> <flushonexecutestatement="insertAccount"> <flushonexecutestatement="updateAccount"> <flushonexecutestatement="deleteAccountById"> </cachemodel> <update id="updateAccount" parameterclass="Account"> updateACCOUNT set ACC_FIRST_NAME=#firstName# , ACC_LAST_NAME = #lastName# ,ACC_EMAIL =#emailAddress# where ACC_ID = #id# </update>
Cache规则Type 目前有4种实现。建议用LRU或者OsCache readOnly，表示Cache对象是否只读。False，表示外部更改cache内容无效。 Serialize，是否序列化。true，表示存贮到cache中的是系列化后的对象。 组合： readOnly=false, Serialize=false：Cache Session有效。如:1+n时，下次1+n将会失效。 不系列化，外部更改有效。 readOnly=true, Serialize=false：所有session共享Cache，取出时实例是同一个。不系列化，外部更改有效。默认的 readOnly=false, Serialize=true：所有session共享Cache，取出时实例不一样，但是内容一样。 系列化，外部更改无效 readOnly=true, Serialize=true： 同默认效果一样。 看得出，主要是通过系列化来保证外部更改属性后不影响其它session的取出的结果。 4种Cache实现- LRU，最后使用的排到前面。Cache溢出时，最远被使用的就被clear。
- FIFO，先进先出。
- Memory，内存引用。该实现无数量限制。前两种是基于jvm实现。
- WEAK，产生内存回收动作时，失效。
- SOFT，内存不足时，失效。
- STRONG，显式刷新时，失效。
- OsCache(支持分布式)。通过oscahce.properties控制。
适应范围- 频繁查询，很少更改的内容。如：分类等。
- 1+n查询。n是父类，数据量较少。如：查询Spu信息时，同意需要获得其品类信息。
- 效率低，执行频率高的SQL。如统计一类的SQL。
- 有了Cache机制后，1+n不再可怕。
