Hibernate READ_WRITE CacheConcurrencyStrategy如何工作

介绍

在我以前的文章中，我介绍了NONSTRICT_READ_WRITE二级缓存并发机制。在本文中，我将使用READ_WRITE策略继续本主题。

直写式缓存

NONSTRICT_READ_WRITE是一种通读缓存策略，可更新最终无效的缓存条目。尽管这种策略可能很简单，但是随着写入操作的增加，性能会下降。对于需要大量写入的应用程序，直写式高速缓存策略是更好的选择，因为高速缓存条目可以被日期化而不是被丢弃。

因为数据库是记录系统，并且数据库操作被包装在物理事务中，所以可以同步更新缓存（例如TRANSACTIONAL缓存并发策略的情况）或异步更新（在提交数据库事务之后）。

READ_WRITE策略是一种异步缓存并发机制，为了防止数据完整性问题（例如，陈旧的缓存条目），它使用了提供工作单元隔离保证的锁定机制。

插入资料

因为持久化的实体是唯一标识的（每个实体都分配给一个不同的数据库行），所以新创建的实体会在提交数据库事务后立即缓存：

@Override
public boolean afterInsert(Object key, Object value, Object version) throws CacheException {region().writeLock( key );try {final Lockable item = (Lockable) region().get( key );if ( item == null ) {region().put( key, new Item( value, version, region().nextTimestamp() ) );return true;}else {return false;}}finally {region().writeUnlock( key );}
}

对于要在插入时进行缓存的实体，它必须使用SEQUENCE生成器，该缓存由EntityInsertAction填充：

@Override
public void doAfterTransactionCompletion(boolean success, SessionImplementor session) throws HibernateException {final EntityPersister persister = getPersister();if ( success && isCachePutEnabled( persister, getSession() ) ) {final CacheKey ck = getSession().generateCacheKey( getId(), persister.getIdentifierType(), persister.getRootEntityName() );final boolean put = cacheAfterInsert( persister, ck );}}postCommitInsert( success );
}

IDENTITY生成器不能与事务性的后写式第一级缓存设计配合使用，因此关联的EntityIdentityInsertAction不会缓存新插入的条目（至少在修复HHH-7964之前）。

从理论上讲，在数据库事务提交和第二级高速缓存插入之间，一个并发事务可能会加载新创建的实体，因此触发高速缓存插入。虽然可能，但缓存同步滞后非常短，如果并发事务被交错，则只会使另一个事务命中数据库，而不是从缓存中加载实体。

更新资料

尽管插入实体是一个相当简单的操作，但是对于更新，我们需要同步数据库和缓存条目。 READ_WRITE并发策略采用锁定机制来确保数据完整性：

Hibernate Transaction提交过程触发会话刷新
EntityUpdateAction用Lock对象替换当前缓存条目
update方法用于同步缓存更新，因此在使用异步缓存并发策略（如READ_WRITE）时不会执行任何操作
提交数据库事务后，将调用after-transaction-completion回调
EntityUpdateAction调用EntityRegionAccessStrategy的afterUpdate方法
ReadWriteEhcacheEntityRegionAccessStrategy将Lock条目替换为实际的Item ，从而封装了实体分解状态

删除资料

从下面的序列图中可以看出，删除实体与更新过程类似：

Hibernate Transaction提交过程触发会话刷新
EntityDeleteAction用Lock对象替换当前的缓存条目
remove方法调用不执行任何操作，因为READ_WRITE是异步缓存并发策略
提交数据库事务后，将调用after-transaction-completion回调
EntityDeleteAction调用EntityRegionAccessStrategy的unlockItem方法
ReadWriteEhcacheEntityRegionAccessStrategy用另一个超时时间增加的Lock对象替换Lock条目

删除实体后，其关联的二级缓存条目将被一个Lock对象代替，该对象将发出任何随后的请求以从数据库读取而不是使用缓存条目。

锁定构造

Item和Lock类都继承自Lockable类型，并且这两个类都有一个特定的策略，允许读取或写入缓存条目。

READ_WRITE 锁定对象

Lock类定义以下方法：

@Override
public boolean isReadable(long txTimestamp) {return false;
}@Override
public boolean isWriteable(long txTimestamp, Object newVersion, Comparator versionComparator) {if ( txTimestamp > timeout ) {// if timedout then allow writereturn true;}if ( multiplicity > 0 ) {// if still locked then disallow writereturn false;}return version == null? txTimestamp > unlockTimestamp: versionComparator.compare( version, newVersion ) < 0;
}

Lock对象不允许读取缓存条目，因此任何后续请求都必须发送到数据库
如果当前会话创建时间戳大于“锁定超时”阈值，则允许写入缓存条目
如果至少一个会话设法锁定了该条目，则禁止进行任何写操作
如果进入的实体状态已增加其版本，或者当前的会话创建时间戳大于当前的条目解锁时间戳，则可以使用Lock条目进行写操作

READ_WRITE 项目对象

Item类定义以下读取/写入访问策略：

@Override
public boolean isReadable(long txTimestamp) {return txTimestamp > timestamp;
}@Override
public boolean isWriteable(long txTimestamp, Object newVersion, Comparator versionComparator) {return version != null && versionComparator.compare( version, newVersion ) < 0;
}

仅在缓存条目创建时间之后启动的会话中才可读取项目
Item条目仅在传入实体状态已增加其版本时才允许写入

缓存条目并发控制

当保存和读取底层缓存条目时，将调用这些并发控制机制。

在调用ReadWriteEhcacheEntityRegionAccessStrategy get方法时读取缓存条目：

public final Object get(Object key, long txTimestamp) throws CacheException {readLockIfNeeded( key );try {final Lockable item = (Lockable) region().get( key );final boolean readable = item != null && item.isReadable( txTimestamp );if ( readable ) {return item.getValue();}else {return null;}}finally {readUnlockIfNeeded( key );}
}

缓存条目由ReadWriteEhcacheEntityRegionAccessStrategy putFromLoad方法编写：

public final boolean putFromLoad(Object key,Object value,long txTimestamp,Object version,boolean minimalPutOverride)throws CacheException {region().writeLock( key );try {final Lockable item = (Lockable) region().get( key );final boolean writeable = item == null || item.isWriteable( txTimestamp, version, versionComparator );if ( writeable ) {region().put( key, new Item( value, version, region().nextTimestamp() ) );return true;}else {return false;}}finally {region().writeUnlock( key );}
}

超时

如果数据库操作失败，则当前高速缓存条目将保留一个Lock对象，并且无法回滚到其先前的Item状态。由于这个原因，锁必须超时，以允许将缓存条目替换为实际的Item对象。 EhcacheDataRegion定义以下超时属性：

private static final String CACHE_LOCK_TIMEOUT_PROPERTY = "net.sf.ehcache.hibernate.cache_lock_timeout";
private static final int DEFAULT_CACHE_LOCK_TIMEOUT = 60000;

除非我们重写net.sf.ehcache.hibernate.cache_lock_timeout属性，否则默认超时为60秒：

final String timeout = properties.getProperty(CACHE_LOCK_TIMEOUT_PROPERTY,Integer.toString( DEFAULT_CACHE_LOCK_TIMEOUT )
);

以下测试将模拟失败的数据库事务，因此我们可以观察到READ_WRITE缓存如何仅在超时阈值到期后才允许写入。首先，我们将降低超时值，以减少缓存冻结时间：

properties.put("net.sf.ehcache.hibernate.cache_lock_timeout", String.valueOf(250));

我们将使用自定义拦截器手动回滚当前正在运行的事务：

@Override
protected Interceptor interceptor() {return new EmptyInterceptor() {@Overridepublic void beforeTransactionCompletion(Transaction tx) {if(applyInterceptor.get()) {tx.rollback();}}};
}

以下例程将测试锁定超时行为：

try {doInTransaction(session -> {Repository repository = (Repository)session.get(Repository.class, 1L);repository.setName("High-Performance Hibernate");applyInterceptor.set(true);});
} catch (Exception e) {LOGGER.info("Expected", e);
}
applyInterceptor.set(false);AtomicReference<Object> previousCacheEntryReference =new AtomicReference<>();
AtomicBoolean cacheEntryChanged = new AtomicBoolean();while (!cacheEntryChanged.get()) {doInTransaction(session -> {boolean entryChange;session.get(Repository.class, 1L);try {Object previousCacheEntry = previousCacheEntryReference.get();Object cacheEntry = getCacheEntry(Repository.class, 1L);entryChange = previousCacheEntry != null &&previousCacheEntry != cacheEntry;previousCacheEntryReference.set(cacheEntry);LOGGER.info("Cache entry {}", ToStringBuilder.reflectionToString(cacheEntry));if(!entryChange) {sleep(100);} else {cacheEntryChanged.set(true);}} catch (IllegalAccessException e) {LOGGER.error("Error accessing Cache", e);}});
}

运行此测试将生成以下输出：

selectreadwritec0_.id as id1_0_0_,readwritec0_.name as name2_0_0_,readwritec0_.version as version3_0_0_
fromrepository readwritec0_
wherereadwritec0_.id=1updaterepository
setname='High-Performance Hibernate',version=1
whereid=1 and version=0JdbcTransaction - rolled JDBC Connectionselectreadwritec0_.id as id1_0_0_,readwritec0_.name as name2_0_0_,readwritec0_.version as version3_0_0_
fromrepository readwritec0_
wherereadwritec0_.id = 1Cache entry net.sf.ehcache.Element@3f9a0805[key=ReadWriteCacheConcurrencyStrategyWithLockTimeoutTest$Repository#1,value=Lock Source-UUID:ac775350-3930-4042-84b8-362b64c47e4b Lock-ID:0,version=1,hitCount=3,timeToLive=120,timeToIdle=120,lastUpdateTime=1432280657865,cacheDefaultLifespan=true,id=0
]
Wait 100 ms!
JdbcTransaction - committed JDBC Connectionselectreadwritec0_.id as id1_0_0_,readwritec0_.name as name2_0_0_,readwritec0_.version as version3_0_0_
fromrepository readwritec0_
wherereadwritec0_.id = 1Cache entry net.sf.ehcache.Element@3f9a0805[key=ReadWriteCacheConcurrencyStrategyWithLockTimeoutTest$Repository#1,value=Lock Source-UUID:ac775350-3930-4042-84b8-362b64c47e4b Lock-ID:0,version=1,hitCount=3,timeToLive=120,timeToIdle=120,lastUpdateTime=1432280657865,cacheDefaultLifespan=true,id=0
]
Wait 100 ms!
JdbcTransaction - committed JDBC Connectionselectreadwritec0_.id as id1_0_0_,readwritec0_.name as name2_0_0_,readwritec0_.version as version3_0_0_
fromrepository readwritec0_
wherereadwritec0_.id = 1
Cache entry net.sf.ehcache.Element@305f031[key=ReadWriteCacheConcurrencyStrategyWithLockTimeoutTest$Repository#1,value=org.hibernate.cache.ehcache.internal.strategy.AbstractReadWriteEhcacheAccessStrategy$Item@592e843a,version=1,hitCount=1,timeToLive=120,timeToIdle=120,lastUpdateTime=1432280658322,cacheDefaultLifespan=true,id=0
]
JdbcTransaction - committed JDBC Connection

第一个事务尝试更新实体，因此在提交事务之前，关联的第二级缓存条目已被锁定。
第一个事务失败，它被回滚
持有锁，因此接下来的两个连续事务将进入数据库，而不用当前已加载的数据库实体状态替换Lock条目
在Lock超时期限到期后，第三笔交易最终可以用Item缓存条目替换Lock （保持实体分解为水合状态 ）

结论

READ_WRITE并发策略具有直写式缓存机制的优点，但是您需要了解它的内部工作原理，才能确定它是否适合您当前的项目数据访问要求。

对于繁重的写争用方案，锁定结构将使其他并发事务进入数据库，因此您必须确定同步高速缓存并发策略是否更适合这种情况。

代码可在GitHub上获得。

翻译自: https://www.javacodegeeks.com/2015/05/how-does-hibernate-read_write-cacheconcurrencystrategy-work.html