Oscache的强行更新机制
2006-06-21 20:18
302 查看
背景 :
在产品中也许不需要强行更新,但是测试的时候往往需要。
part 1
当你强行更新缓存时会发生如下步骤:
step1)
GeneralCacheAdministrator.flushAll----->
step2)
Cache.flushAll(Date date, String origin)
flushAll的源代码如下:
public void flushAll(Date date, String origin) {
//更新Cache的flushDateTime
flushDateTime = date;
//通知监听器更新事件,如果你没有注册监听器,这个方法没用
dispatchCachewideEvent(CachewideEventType.CACHE_FLUSHED, date, origin);
}
也就是说强行更新时仅仅只是修改Cache的flushDateTime 属性
并不是更改数据
part 2
接着你刷新页面看你的强行刷新时候有效果
step1)
Cache.getFromCache(String key, int refreshPeriod, String cronExpiry)---->
step2)
Cache.isStale(cacheEntry, refreshPeriod, cronExpiry)----->
看看isStale源代码:
protected boolean isStale(CacheEntry cacheEntry, int refreshPeriod, String cronExpiry) {
boolean result = cacheEntry.needsRefresh(refreshPeriod) || isFlushed(cacheEntry);
//cronExpiry 定义了绝对时间,通常你不会用,所以以下代码没用
if ((cronExpiry != null) && (cronExpiry.length() > 0)) {
try {
FastCronParser parser = new FastCronParser(cronExpiry);
result = result || parser.hasMoreRecentMatch(cacheEntry.getLastUpdate());
} catch (ParseException e) {
log.warn(e);
}
}
return result;
}
step3)
Cache.isFlushed(CacheEntry cacheEntry)
看看isFlushed源代码:
public boolean isFlushed(CacheEntry cacheEntry) {
if (flushDateTime != null) {
long lastUpdate = cacheEntry.getLastUpdate();
return (flushDateTime.getTime() >= lastUpdate);
} else {
return false;
}
}
从上面源代码看出,因为Cache的flushDateTime被更新,所以肯定会大于等于cacheEntry的最后更新时间,所以Cache会认为缓存的数据是stale的,于是从数据库重新取数据。
总而言之:强行更新只是做个标记,并不真正的获取新数据,下次从缓存读数据时,缓存会根据做的标记从数据更新数据,即使还没到更新的时候。
在产品中也许不需要强行更新,但是测试的时候往往需要。
part 1
当你强行更新缓存时会发生如下步骤:
step1)
GeneralCacheAdministrator.flushAll----->
step2)
Cache.flushAll(Date date, String origin)
flushAll的源代码如下:
public void flushAll(Date date, String origin) {
//更新Cache的flushDateTime
flushDateTime = date;
//通知监听器更新事件,如果你没有注册监听器,这个方法没用
dispatchCachewideEvent(CachewideEventType.CACHE_FLUSHED, date, origin);
}
也就是说强行更新时仅仅只是修改Cache的flushDateTime 属性
并不是更改数据
part 2
接着你刷新页面看你的强行刷新时候有效果
step1)
Cache.getFromCache(String key, int refreshPeriod, String cronExpiry)---->
step2)
Cache.isStale(cacheEntry, refreshPeriod, cronExpiry)----->
看看isStale源代码:
protected boolean isStale(CacheEntry cacheEntry, int refreshPeriod, String cronExpiry) {
boolean result = cacheEntry.needsRefresh(refreshPeriod) || isFlushed(cacheEntry);
//cronExpiry 定义了绝对时间,通常你不会用,所以以下代码没用
if ((cronExpiry != null) && (cronExpiry.length() > 0)) {
try {
FastCronParser parser = new FastCronParser(cronExpiry);
result = result || parser.hasMoreRecentMatch(cacheEntry.getLastUpdate());
} catch (ParseException e) {
log.warn(e);
}
}
return result;
}
step3)
Cache.isFlushed(CacheEntry cacheEntry)
看看isFlushed源代码:
public boolean isFlushed(CacheEntry cacheEntry) {
if (flushDateTime != null) {
long lastUpdate = cacheEntry.getLastUpdate();
return (flushDateTime.getTime() >= lastUpdate);
} else {
return false;
}
}
从上面源代码看出,因为Cache的flushDateTime被更新,所以肯定会大于等于cacheEntry的最后更新时间,所以Cache会认为缓存的数据是stale的,于是从数据库重新取数据。
总而言之:强行更新只是做个标记,并不真正的获取新数据,下次从缓存读数据时,缓存会根据做的标记从数据更新数据,即使还没到更新的时候。
相关文章推荐
- Oscache的强行更新机制
- 概览最有前景的下一代嵌入式 Linux 软件更新机制
- 如何实现缓存系统的更新机制
- 如何实现缓存系统的更新机制
- Openstack安全更新的流程和机制
- Android的消息机制,用Android线程间通信的Message机制,Android中Handler的使用方法——在子线程中更新界面,handler机制
- Python代码模块热更新机制实现(reload)
- Android应用程序组件Content Provider的共享数据更新通知机制分析
- MFC菜单的命令更新机制
- mysql查询更新时的锁表机制分析
- MFC菜单更新机制
- Android的消息机制,用Android线程间通信的Message机制,Android中Handler的使用方法——在子线程中更新界面,handler机制
- 灵活正确的实现.NET插件机制开发者在线 Builder.com.cn 更新时间:2008-08-05作者: 来源:开发者在线
- 《Apache Kylin处理分表时间戳更新机制》
- AppHub:绕过苹果审核机制更新iOS App
- Kafka源码分析Producer读取Metadata的数据结构及Metadata两种更新机制介绍
- mysql查询更新时的锁表机制分析
- DataSet 强行更新的狂想
- Android应用程序组件Content Provider的共享数据更新通知机制分析(1)
- mysql查询更新时的锁表机制分析