如果阻塞工作线程，则需要确保仅在合理的时间内阻塞线程。正如前面提到的，单个工作线程无法并行处理多个事务。因此，由于阻塞工作线程会等待某个远程服务发送的响应，因此无法继续处理当前事务，也无法开始处理新事务。对于存在很多阻塞工作线程的情况，在完成正在处理的事务之前，新工作将无法执行，而这意味着新工作必须排队，等待有可用资源时处理。

    WebSphere Application Server for z/OS 之类的产品提供了某种排队机制，能够尝试消除阻塞线程的一些影响。这些队列用于在线程不可用时临时接收请求。在工作线程完成其事务后，将会执行队列中的下一个工作项目。

    被阻塞的应用程序服务器工作线程可能会对服务器的容量和吞吐量造成负面影响。由于单个托管线程在一次只能执行一个事务，阻塞线程会导致当前线程无法完成，从而使得工作线程无法执行下一个工作单元。

    图 5 显示了一个客户体系结构，其中远程服务从应用程序服务器通过非托管网络进行调用。对银行设备的每次服务调用都会阻塞服务器内的工作线程。可以使用超时来约束和控制阻塞工作线程的时间量。例如，如果所有远程方法调用（Remote Method Invocation，RMI）调用必须在 120 秒内完成，则对银行设备的每次服务调用最多花费 120 秒时间。

     
    图 5. 示例客户拓扑

    假定出现了某个网络问题，例如，靠近设备的路由器出错，或一组设备出错。图 6 显示了应用程序服务器内此类错误的潜在影响。很多工作线程可能会突然阻塞，并等待超时过期，不过同时又有新工作送到服务器。如果服务器的服务处理速率低于传入工作的速率，请求则会在队列中堆积起来。高级应用程序服务器产品（如 WebSphere Application Server for z/OS）会在工作队列过长的情况下采取一些措施。例如，可以执行第二个工作超时，并拒绝为新请求提供服务。

    
    图 6. 网络问题及其对客户拓扑的影响

    可以采取称为 EC3 abend 的措施，此方法中将应用程序服务器的部分内容（本例中的 WebSphere Application Server for z/OS 服务区域）认定为挂起，因此将其重新启动。重新启动 WebSphere Application Server 服务区域将导致所有正在进行的事务回滚，从而会给数据库造成额外的负载。根据图 1 中所示，事务回滚可能会影响共享运行时环境中运行的其他工作。形成堆栈的同步服务（例如图 4 中所示的场景）也可能受到影响；位于堆栈服务链靠后位置的服务执行速度可能会比较慢，从而减少了其调用方的吞吐量。在最复杂的环境中，单个服务可能会存在连锁效应，导致不相关的服务和子系统崩溃，如图 7 中所示的场景。