这是开发配置管理器代理(CMP)应用程序中大型任务中的一部分,并且是 CMP 的某项高级功能。
使用 CMP 可能将多个针对相同配置管理器的请求合为一组,并将它们作为单个工作单元提交。
要启动批处理,应用程序必须调用 ConfigManagerProxy 句柄上的 beginUpdates() 方法。 这会告诉 CMP 保留不向配置管理器提交任何更改状态的请求,直至告之其可以如此操作为止。 sendUpdates() 方法告诉 CMP 将自上一次 beginUpdates() 调用以来收到的任何请求作为批处理进行提交,而 clearUpdates() 可以用于废弃没有向配置管理器提交的批处理。通过使用 isBatching() 方法可以确定是否当前有批处理正在进行。 请注意,对于每个 CMP 句柄,只能有一个批处理正在进行。
使用批处理方法的一个优点是它确保没有其他应用程序在批处理期间可以有配置管理器处理的消息。当配置管理器收到批处理请求时,它按照每个请求添加至批处理(FIFO)的顺序在批处理中对其进行处理,并处理未由其他 CMP 应用程序处理的请求,直至整个批处理完成。
BrokerProxy b2 = topology.createBroker("B2", "QMB2"); ExecutionGroupProxy e = b2.createExecutionGroup("default"); b2.deploy();
不使用批处理方法,就不可能保证这些操作成功。例如,即便每个命令都成功,但是在处理其他两个命令之前,第二个(可能是远程)应用程序也可能在第一个应用程序创建了代理 B2 后将其删去。
cmp.startUpdates(); BrokerProxy b2 = topology.createBroker("B2", "QMB2"); ExecutionGroupProxy e = b2.createExecutionGroup("default"); b2.deploy(); cmp.sendUpdates();
使用批处理方法的另一个优点是性能。 CMP 通常对于每个请求会将一条 WebSphere MQ 消息发送至配置管理器。在快速会话中,需要发送大量请求的情况下(例如,创建主题层次结构),批处理方法对于处理请求所花时间及内存相关的性能就有重要影响。 请求的每个批处理会在单个 WebSphere MQ 消息中进行发送,因此每个方法的开销也会大大降低。
批处理方式不提供事务性的(提交和回退)功能;因此批处理中的某些请求可能成功,其他的可能失败。如果配置管理器处理批处理中的某个请求失败,它会不管该失败,继续处理批处理中的下一个请求。