Hibernate的ReadWriteCache分析及在集群环境下之分析

Hibernate的ReadWriteCache分析及在集群环境下之分析:

ReadWriteCache与读写锁:
ReadWriteCache从名字上看，我们联想到该实现与读写锁有关。读写锁的特征，可并发读，读写互斥，写互斥。
读方法的比较:
读方法实现如下:

public synchronized Object get(Object key, long txTimestamp) throws CacheException {
			Lockable lockable = (Lockable) cache.get(key);

			boolean gettable = lockable!=null && lockable.isGettable(txTimestamp);

			if (gettable) {
				return ( (Item) lockable ).getValue();
			}
			return null;
	}

1.如果单纯从该方法的声明来说，该方法是同步的，显然不满足读写锁并发读的特性。但是仔细考虑，并发的范围是什么，如果我们把并发的范围放大到事务呢，那么是满足并发读这个条件的。
2.从读写互斥的角度看，当存在写锁的时候，获得读锁的调用将会被阻塞直到写锁被释放。首先，这段代码不存在获得读锁的调用，我们注意到判断lockable.isGettable(txTimestamp)，这个判断所达到的目的,当存在对Cache数据的修改操作时，读无效。
从而，达到读写互斥的目的。
因此，get方法是满足读并发，读写互斥的条件的。


写方法的比较：
写方法实现如下:

public synchronized boolean put(
			Object key, 
			Object value, 
			long txTimestamp, 
			Object version, 
			Comparator versionComparator,
			boolean minimalPut) 
	throws CacheException {
		try {
			cache.lock(key);

			Lockable lockable = (Lockable) cache.get(key);

			boolean puttable = lockable==null || 
				lockable.isPuttable(txTimestamp, version, versionComparator);

			if (puttable) {
				cache.put( key, new Item( value, version, cache.nextTimestamp() ) );
				return true;
			}
			return false;
		}
		finally {
			cache.unlock(key);
		}
	}

题外话，不同jvm实例下如何实现原子操作：
1.道理同一个jvm的情况，无非是对同一个资源的竞争。cache.lock(key),cache.unlock(key)所起到的作用就是跨jvm的同步，即是对key所标识的资源的竞争。
2.注意到调用:isPuttable,这个判读所达到的目的，当存在对Cache数据的修改操作时，那么写无效，从而达到写互斥的目的。如果我们仔细寻找代码。会发现，在删除和修改数据时，Hibernate在事务提交前会调用lock操作来产生写锁，从而阻塞了其它事务的读写，在事务提交后，才解锁。所以我们再一次发现，互斥范围是在事务范围而不是在实例方法调用范围。(但是,对于put方法，该实现并不是严格的事务范围互斥，在版本比较更新的时候，put调用会生效)

从上面分析看，该实现是遵照ReadWriteLock的工作方式的。
额外的关注:
txTimestamp,在会话构建的时候，会给每个会话分配一个timestamp,起到对会话标识以及排序的作用。
txTimestamp有序的作用：
1.对于实现可重复读隔离级别，由于cache数据可能被新的事务所覆盖，因此，如果老的事务
读取该cache数据，则不满足可重复读条件。在这种情况下，将读操作交有数据库来处理，则可满足事务隔离级别的要求。
(事实上，即使这么做也不能完全满足可重复读，如果第一次读从cache而不是数据库)
2.当解锁完成后，锁覆盖的判断。
概括来说，因为并发发生在事务范围，所以通过txTimestamp体现事务的有序性是必须的。

下面我们分析在集群环境下使用ReadWriteLock的现状以及需要做的工作。
目前，hibernate所提供的Cache实现中，没有一个实现了lock方法。所以是不能在集群环境下工作的。
必要充分条件:
1.cache实现事务唯一标识产生器，即nextTimestamp方法
2.cache实现lock,unlock,update方法，从实现跨jvm的资源竞争，达到跨jvm的同步的目的。

问题分析:
开销上,一次更新或删除操作，跨jvm的资源竞争操作大约有7次。唯一标识产生器调用有2次。
一次缓存写操作，跨jvm的资源竞争操作大约有2次。唯一标识产生器调用有1次。
锁超时的设置值多少为合理?

其它考虑:
如果按照下面的性能测试，使用memcached+ReadWriteCache还是值得考虑的
http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html