等待资源适配器完成，或者被清理干净。相反，服务器可以通过调用 Work 

 

对象的 release 

 

方法，给资源适配器发信号。然后资源适配器应当尽快完成处理。清单 4 

 

显示了 release 方

法使用的一个示例：

 

　　清单 4. Work 对象的示例
1 public class ExampleWork implements Work {
2     private volatile boolean _released;
3     void run() {
4         for (int i = 0; i < 100; i++) {
5             if (_released) break;
6             // Do something
7         }
8     }
9     void release() {
10         _released = true;
11     }
12     
13 }

 

　　注意清单 4 

 

中使用的关键字 volatile

 

。在 run 方法正进行其处理的同时，会在一个独

 

立的线程上调用 release 方法，volatile 

 

修饰符确保 run 方法能够看到更新的字段。

　　doWork 

 

方法也可能失败，抛出一个名称古怪的 WorkCompletedException 异常。这个

 

异常是在将 run 方法分配给一个线程时抛出的，但这个异常或者是上下文设置失败，或
者是通过抛出运行时异常退出方法。doWork 方法会提供一个错误代码，表示这些故障发
生的路径，还把问题原因作为链接的异常提供。

   

　　　　 为什么等待?

 

　　您已经看到 doWork 方法允许您在调用线程阻塞的同时执行工作。但是如果您不想等

 —— 

待

也就是说，如果您不想同步执行工作，该怎么办呢 ?  

在 Java 2 平台标准版本

(J2SE)环境中，可以使用多线程实现这一目标。但是，J2EE 规范让应用程序服务器使用

 

Java 2 安全管理器防止应用程序离开自己的线程。如果应用服务器的这部分功能是通过

 

EJB 

 

池或 servlet 池来提供并发性，那么这样做是合理的。服务器也可能想把各种形式的上

下文都关联到一个线程上，因为产生新线程时，上下文可能会丢失。最后，正如我以前讨
论过的，不受服务器控制的线程会造成有序关机很难实现。

 

　　虽然可以通过使用安全策略，逐个案例地克服这个限制，但是 WorkManager 上的 
startWork 

 

和 scheduleWork 方法可以让资源适配器异步地处理工作，同时确保应用程序服

务器仍然在控制之下。startWork 方法会一直等候，直到工作片断开始执行，但不用等到工
作结束。所以，如果调用器需要知道工作是否已经得以执行，但是不需要等到工作完成，
那么可以使用这种方法。相比之下，只要该工作调度被接受，scheduleWork 方法就立即返