Oscache的強行更新機制

背景 ：

在產品中也許不需要強行更新，但是測試的時候往往需要。

part 1

當你強行更新快取時會發生如下步驟：

step1)

generalcacheadministrator.flushall----->

step2)

cache.flushall(date date, string origin)

flushall的源**如下：

public void flushall(date date, string 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) catch (parseexception e)

}return result;

}step3)

cache.isflushed(cacheentry cacheentry)

看看isflushed源**：

public boolean isflushed(cacheentry cacheentry) else

}從上面源**看出，因為cache的

flushdatetime被更新，所以肯定會大於等於cacheentry的最後更新時間，所以cache會認為快取的資料是stale的，於是從資料庫重新取資料。

總而言之：強行更新只是做個標記，並不真正的獲取新資料，下次從快取讀資料時，快取會根據做的標記從資料更新資料，即使還沒到更新的時候。

Oscache的強行更新機制

背景 在產品中也許不需要強行更新，但是測試的時候往往需要。part 1 當你強行更新快取時會發生如下步驟 step1 generalcacheadministrator.flushall step2 cache.flushall date date,string origin flushall的源 ...

Oscache的強行更新機制

背景 在產品中也許不需要強行更新，但是測試的時候往往需要。part 1 當你強行更新快取時會發生如下步驟 step1 generalcacheadministrator.flushall step2 cache.flushall date date,string origin flushall的源 ...

MFC選單命令更新機制

1 mfc當要顯示選單時，作業系統會發出wm initmenupopup訊息，然後由程式視窗的基類接管。此時會建立乙個ccmdui物件，並與程式的第乙個選單相互關聯，呼叫該物件的乙個成員函式doupdate 這個函式發出on update command ui訊息。這條訊息帶有乙個指向ccmdui物...