Java SE 环境中的对象池

通过 Java SE (或其他框架 (例如 Spring)) ，编程模型非常灵活。 因此，单个池策略并非适合所有模型。 您应该考虑是否有一个框架，可以建立任何形式的池，例如 Spring。

否则，应用程序逻辑会执行此操作。 问问自己应用程序本身有多复杂？ 最好了解一下应用程序以及应用程序对指向消息传递系统的连接的要求什么。 应用程序通常也会在其自己的包装程序代码中围绕基本 JMS API 进行编写。

这可能是非常敏感的方法，并且可以隐藏复杂性，但是需要引起注意的是它也可能引入问题。 例如，频繁调用的通用 getMessage() 方法不应仅打开和关闭使用者。

您应当考虑的几点：
  • 应用程序需要多久才能访问 IBM® MQ? 一直，还是只是偶尔。
  • 消息发送的频率是多少？ 频率越低，与 IBM MQ 的单个连接可以共享的次数越多。
  • 连接断开异常通常表明需要重新创建合用的连接。 相关内容：
    • 安全性异常或主机不可用
    • 队列已满异常
  • 如果发生连接中断异常，池中其他空闲连接将发生什么情况？ 应将它们关掉并重新创建吗？
  • 例如，如果正在使用 TLS，您希望单个连接保持打开的时间为多少？
  • 加入池的连接如何标识自己，使得队列管理器可以发现该连接并对其进行跟踪。
您应该考虑所有 JMS 对象以进行池化，并在可能时对该对象进行池化。 这些对象包括：
  • JMS 连接
  • Session
  • 上下文
  • 所有不同类型的生产者和使用者

使用客户机传输时， JMS 连接，会话和上下文将在与 IBM MQ 队列管理器通信时使用套接字。 通过汇集这些对象，节省了与队列管理器的入局 IBM MQ 连接数 (hConns) 以及通道实例数的减少。

使用队列管理器绑定传输彻底移除网络层。 但是，许多应用程序使用客户机传输提供可用性更高、工作负载更均衡的配置。

JMS 生产者和使用者打开队列管理器上的目标。 如果打开的队列或主题数量较少，并且应用程序多个部分在使用这些对象，那么为这些项建立池可能非常有用。

从 IBM MQ 的角度来看，此过程将保存一系列 MQOPEN 和 MQCLOSE 操作。

连接、会话和上下文

这些对象都将 IBM MQ 连接句柄封装到队列管理器，并且是从 ConnectionFactory生成的。 您可以将逻辑添加到应用程序以将连接和从单个连接工厂创建的其他对象的数量限制为具体数量。

您可在应用程序中使用简单数据结构以包含所创建的连接。 需要使用其中一个数据结构的应用程序代码可以检出要使用的对象。

需考虑以下因素：
  • 什么时候从池移除连接？ 通常，在连接上创建异常侦听器。 调用该侦听器来处理异常时，您应该重新创建连接以及之前从该连接创建的任何会话。
  • 如果 CCDT 正在用于均衡工作负载，那么连接可能转到其他队列管理器。 这可能适用于池需求。

请记住， JMS 规范声明多个线程同时访问一个会话或上下文是编程错误。 IBM MQ JMS 代码尝试严格处理线程。 但是，您应该向应用程序添加逻辑，以确保同时只有一个线程在使用会话或上下文对象。

生产者和使用者

所创建的每个生产者和使用者打开队列管理器上的目标。 如果同样的目标将用于各种任务，让使用者或生产者对象保持打开是有意义的。 仅在所有工作都完成时关闭对象。

尽管打开和关闭目标是短操作，但是如果频繁采取此操作，也可能花费很多时间。

这些对象的作用域在创建它们的会话或上下文中，因此需要将其保留在该作用域中。 通常，应用程序的编写方式使得这样做非常直接。

监视

应用程序将如何监视其对象池？ 此问题的答案很大程度上由实现的池解决方案的复杂性确定。

如果您考虑 JavaEE 池实现，那么有大量选项，包括:
  • 池的当前大小
  • 花费在池上的时间对象
  • 清除池
  • 连接的更新

您还应该考虑单个重复使用的会话如何显示在队列管理器上。 识别应用程序的连接工厂属性（例如 appName）可能非常有用。