现在,如果您单击浏览器中的 reload 按钮,testCache.php 脚本将不会再次调用 getOrderFields 和 getOrderItems 函数。相反,它将从本地缓存中读取它们的结果。
因此,从现在起的 24 小时(因为 lifeTime 设置为 86400 秒)以内,本地缓存即可满足使用 order_no=2108 的每个 getOrderFields 或 getOrderItems 调用的需要。但请注意,Cache_Lite_Function 类未提供 API 来测试具有给定参数的给定函数是否存在可用缓存。因此,要确定每次使用相同参数调用函数时应用程序是实际上读取缓存还是仍执行该函数可能有点棘手。例如,在以上示例中,要确保缓存机制正常工作,您可以临时更改 connect.php 脚本中指定的连接信息,以便它无法建立数据库连接;比如指定一个错误的数据库服务器主机名称,然后再次使用 order_no=2108 运行 testCache.php 脚本。如果缓存正常工作,浏览器的输出应与先前的一样。
此外,您还可以检查缓存目录,该目录作为 cacheDir 选项的值(在该示例中为 /tmp)传递给 Cache_Lite_Function 类的构造函数。在该目录中,您将找到两个刚创建的缓存文件,这些文件的名称类似于:cache_7b181b55b55aee36ad5e7bd9d5a091ec_3ad04d3024f4cd54296f75c92a359154。注意,如果您是一位 Windows 用户,则可能要使用 %SystemDrive%\temp 目录保存缓存文件。如果是这样,则必须将 cacheDir 选项设置为 /temp/。
验证缓存机制正常工作后,可以接着创建一个 PHP 来处理从数据库服务器收到的更改通知。“清单 8”是 dropResult.php 脚本。数据库服务器将调用该脚本来响应 ORDERS 和 ORDER_ITEMS 表的更改。
清单 8. 处理从数据库服务器收到的更改通知
<?php
//File:dropResults.php
require_once 'Cache/Lite/Function.php';
$options = array(
'cacheDir' => '/tmp/'
);
$cache = new Cache_Lite_Function($options);
if (isset($_GET['order_no'])&& isset($_GET['table'])) {
if($_GET['table']=='ORDER_ITEMS'){
$cache->drop('getOrderItems', $_GET['order_no']);
}
if ($_GET['table']=='ORDERS'){
$cache->drop('getOrderFields', $_GET['order_no']);
}
}
?>
创建 dropResult.php 脚本后,请确保在通知处理程序中指定的 URL(如清单 2 所示)正确。然后,在 SQL*Plus 或类似工具中以 OE/OE 连接,并执行 UPDATE 语句,这些语句将影响本部分先前通过 testCache.php 脚本访问的同一订单(此处是 ID 为 2408 的订单):
UPDATE ORDERS SET order_mode = 'direct' WHERE order_id=2408; UPDATE ORDER_ITEMS SET quantity = 3 WHERE order_id=2408 AND line_item_id=1; UPDATE ORDER_ITEMS SET quantity = 1 WHERE order_id=2408 AND line_item_id=2; COMMIT;
为响应以上更新,本文前面介绍的通知处理程序将逐个使用下列 URL 运行 dropResults.php 脚本两次:
http://webserverhost/phpcache/dropResults.php?order_no=2408&table=ORDERS http://webserverhost/phpcache/dropresults.php?order_no=2408&table=ORDER_ITEMS
从“清单 8”中您可以清楚地看到,dropResult.php 脚本在从数据库服务器收到更改通知后并未刷新缓存。它只是删除了包含过期数据的缓存文件。因此,如果现在检查缓存目录,则将看到在使用 order_no=2408 运行 testCache.php 脚本时创建的缓存文件已经消失。这实际上意味着,testCache.php 在下次请求与 ID 为 2408 的订单相关的数据时将从后端数据库而非本地缓存中获取该数据。
您会发现,在应用程序请求的结果集很有可能在应用程序使用它之前更改的情况下该方法将很有用。就本文的示例而言,这意味着与特定订单相关的数据可能在 testCache.php 访问该订单之前多次更改。这样,应用程序会因在从数据库服务器收到更改通知后立即刷新它的缓存而做了大量不必要的工作。
但如果您希望 dropResult.php 脚本在收到更改通知后立即刷新缓存,则可以在调用 drop 方法后调用 Cache_Lite_Function 实例的 call 方法,并为这两个调用指定相同的参数。在该情形下,还应确保包含 getOrderFields.php 和 getOrderItems.php 脚本,以便 dropResults.php 可以调用 getOrderFields 和 getOrderItems 函数来刷新缓存。“清单 9”是修改后的 dropResult.php 脚本。
清单 9. 在收到更改通知后立即刷新缓存
<?php
//File:dropResults.php
require_once 'Cache/Lite/Function.php';
require_once 'getOrderItems.php';
require_once 'getOrderFields.php';
$options = array(
'cacheDir' => '/tmp/',
'lifeTime' => 86400
);
$cache = new Cache_Lite_Function($options);
if (isset($_GET['order_no'])&& isset($_GET['table'])) {
if($_GET['table']=='ORDER_ITEMS'){
$cache->drop('getOrderItems', $_GET['order_no']);
$cache->call('getOrderItems', $_GET['order_no']);
}
if ($_GET['table']=='ORDERS'){
$cache->drop('getOrderFields', $_GET['order_no']);
$cache->call('getOrderFields', $_GET['order_no']);
}
}
?>
如果存储在 ORDERS 和 ORDER_ITEMS 表中的数据很少更改并且应用程序频繁访问它,则以上方法可能很有用。
总结
如果 PHP 应用程序与 Oracle 数据库 10g 第 2 版交互,则可以利用“数据库更改通知特性”,通过该特性应用程序可以接收通知来响应对与发出的请求关联的对象进行的 DML 更改。使用该特性,您不必在特定时间段更新应用程序中的缓存。相反,仅当注册查询的结果集已经更改时才执行该操作。
更多内容请看PCdog.com--PHP与数据库 数据库相关文章专题
