SPI的次要变更环绕着怎样在特定目标下构建缓存地区而睁开。基础上Hibernate必要缓存地区完成四个分歧的目标:实体数据、汇合数据、查询了局实时间戳更新。之前的SPI试图以单一体例处置这些分歧范例数据;实质上它试图以广泛的体例来看待数据缓存而不论所存储数据的特征。可是在理论中我们发明良多时分缓存集成器必要思索到那些分歧特征。比方在集群缓存中,让实体和汇合数据及查询和工夫戳更新地区同时生效也许很成心义。假如不基于地区称号接纳一些手腕的话,之前的SPI是不成能处置这类夹杂婚配的。新的SPI使这些区分变得明晰了然。比方有一个叫做“buildEntityRegion”大概“buildCollectionRegion”的办法,那末缓存集成器就能够断定特定地区的数据范例是能够持有并构建一个得当的设置好的缓存/地区的。JBossCache2.x集成如今是间接利用新的SPI的独一的缓存集成(其他的利用了毗连旧式和新式SPI的桥,如今已不倡议利用了)。一样,它充实使用了我下面提到的那些区分以使得用户能够为分歧地区界说分歧举动。JBossCache2.x相对JBossCache1.x来讲有两个详细的改善有助于Hibernate的利用。第一个是增添了“putForExternalRead”历程。当利用JBossCache1.x,我们在从数据库读取数据并将其放到JBossCache地区中,偶然会碰到功能成绩,乃至还会产生逝世锁。情形是如许的:当我们实验将只读数据放到节点上时,JBossCache必要一个写锁,只管全体操纵的语义必要的是一个读锁。然后该写锁堵塞了其他事件。JBossCache2.x引进了一个针对该用例而出格计划的办法,集成时就利用了该办法。
从利用Hibernate的角度来看JBossCache2.x中其他主要的改善就是它利用悲观锁更好地办理集群中有效的节点。最年夜的改动就是有一个“碑石(tombstone)”来反省有效的实体,如许前面如果实验往缓存中的该实体举行写进操纵时就会晓得有效的版本是甚么而且还会实行一个得当的版本查验。关于Hibernate来讲有效长短常主要的,由于这是最无效的运转集群实体缓存的体例。
当我第一次看到TopLink/OpenJPA时,我恰好在做Hibernate中的BytecodeProvider撑持事情。我真的喜好在类加载时就利用JVM代办署理来静态处置类,而不是在一个独自的构建步骤中举行。Hibernate并没有接纳这类体例,可是我盘算在Hibernate4.0中实验一下,由于当时Hibernate就不再撑持JDK1.4了。
既然3.3.0GA已公布了,我们会有一段工夫来办理JIRA中提出的关于3.3.x的一些成绩。
我们已在制订关于3.4和4.0的企图。一样平常而言,我们还没有真正会商过将来的线路图,可是由于3.4上的事情已入手下手而且其特征集基础上也已断定,我很愿意多说一些。我们将精神会合于功能改善和资本使用和使Hibernate运转在集群的妨碍恢复场景中。别的要说的就是“抓取剖析(fetchprofiles)”的引进,如许你就能够在元数据中创建定名的抓取战略然后在运转时静态使用Session上的那些剖析。关于3.4来讲这些都是年夜问题。
欢迎光临 仓酷云 (http://ckuyun.com/) | Powered by Discuz! X3.2 |