重庆孝爱之家网站建设,佛山网红打卡景点大全排名榜,建设直播网站需要哪些许可证,找项目网JmsTemplate和DefaultMessageListenerContainer是用于访问JMS兼容MOM的Spring帮助器。 他们的主要目标是在JMS API之上形成一层#xff0c;并处理诸如事务管理/消息确认之类的基础结构#xff0c;并隐藏JMS API的某些重复和笨拙的部分#xff08;保留在那里#xff1a; JMS… JmsTemplate和DefaultMessageListenerContainer是用于访问JMS兼容MOM的Spring帮助器。 他们的主要目标是在JMS API之上形成一层并处理诸如事务管理/消息确认之类的基础结构并隐藏JMS API的某些重复和笨拙的部分保留在那里 JMS 2.0即将来临。 要使用这些帮助程序中的任何一个都必须为其提供至少 JMS ConnectionFactory和有效的JMS Destination 。 在应用程序服务器上运行应用程序时很有可能使用JEE架构定义ConnectionFactory。 这简化了添加ConnectionFactory及其配置参数的过程从而允许它们以给定的别名例如jms / myConnectionFactory在目录服务中发布。 在你内 应用程序例如如果需要更多配置来查找ConnectionFactory并将其传递给JmsTemplate和/或DefaultMessageListenerContainer则可以使用JEE命名空间或JndiTemplate / JndiObjectFactoryBean bean中的“ jndi-lookup”。 后者是JMS目的地标识要向其生成消息或从中使用消息的JMS队列或主题。 但是这两个JmsTemplate作为DefaultMessageListenerContainer都有两个不同的属性用于注入目标。 有一种方法将目的地作为String 将目的地作为JMS Destination类型。 Spring并没有发明这种功能 JMS规范提到了两种方法 4.4.4 Creating Destination Objects
Most clients will use Destinations that are JMS administered objects that they have looked up via JNDI. This is the most portable approach.
Some specialized clients may need to create Destinations by dynamically manufacturing one using a provider-specific destination name.
Sessions provide a JMS provider-specific method for doing this. 如果将目标作为String传递则助手将隐藏将它们映射到有效JMS目标所需的额外步骤。 最后JMS会话上的createConsumer希望您在返回MessageConsumer之前传递Destination对象以指示从何处使用消息。 当将目的地配置为String时Spring会使用JMS API本身来查找目的地。 默认情况下JmsTemplate和DefaultMessageListenerContainer具有对DestinationResolver的引用默认情况下为DynamicDestinationResolver 稍后会对此进行详细介绍。 下面的代码是DynamicDestinationResolver的摘录突出显示的行指示使用JMS API将String转换为Destination在此示例中为Queue protected Queue resolveQueue(Session session, String queueName) throws JMSException {if (session instanceof QueueSession) {// Cast to QueueSession: will work on both JMS 1.1 and 1.0.2return ((QueueSession) session).createQueue(queueName);}else {// Fall back to generic JMS Session: will only work on JMS 1.1return session.createQueue(queueName);}} 规范提到的另一种方法JNDI方法是将Destinations配置为应用程序服务器上的可管理对象。 这遵循ConnectionFactory的原理。 该目的地发布在应用程序服务器目录中并且可以通过其JNDI名称例如jms / myQueue进行查找。 再次您可以在应用程序中查找JMS目标并使用以JMS目标为参数的属性将其传递给JmsTemplate和/或DefaultMessageListenerContainer。 现在为什么我们有这两种选择 我一直认为这是在方便性动态方法和环境透明性/可配置性JNDI方法之间选择的问题。 例如在某些情况下物理目标的名称可能会有所不同具体取决于应用程序运行的环境。 如果在应用程序内部配置物理目标名称则显然会失去此好处因为如果不重建应用程序就无法更改它们。 另一方面如果将它们配置为受管理对象则只需更改应用程序服务器配置中的物理目标名称即可。 记得; 可以配置物理目标名称很有意义。 除了目标类型之外处理消息传递的应用程序也不了解其详细信息。 消息传递目标没有功能协定并且其任何属性物理目标持久性等对于您编写的代码都不重要。 实际合同位于消息本身标题和正文内部。 另一方面数据库表只是一个示例它确实暴露了契约并与您的代码紧密结合。 在大多数情况下重命名数据库表确实会影响您的代码因此与消息传递目标相比使这种可配置项通常没有附加值。 最近我发现我对这的理解还不是全部。 该规范摘自上面某些段落的“ 4.4.4创建目标对象”已经给出了提示“大多数客户端将使用目标这些目标是他们通过JNDI查找的JMS管理的对象。 这是最便携的方法。” 基本上这告诉我们另一种方法将目标作为String的动态方法是“最少可移植”的方法。 对我来说这从来都不是很清楚因为每个提供程序都必须实现这两种方法但是必须在更广泛的范围内考虑“便携式”。 当将Destination配置为String时Spring在创建新的JMS Session时默认会将其转换为JMS Desintations。 当使用DefaultMessageListenerContainer消费消息时您处理的每条消息都在事务中发生并且默认情况下JMS会话和使用者没有被合并因此将为每个接收操作重新创建它们。 每次容器检查新消息和/或接收新消息时这都会导致将String转换为JMS Destination。 “非便携式”方面发挥了作用因为这还意味着此转换的细节和成本完全取决于MOM的驱动程序/实现。 在我们的案例中我们在Oracle AQ作为MOM提供商方面经历了这一情况。 每当目标转换发生时驱动程序都会执行一个特定的查询 select /* FIRST_ROWS */ t1.owner, t1.name, t1.queue_table, t1.queue_type, t1.max_retries, t1.retry_delay, t1.retention, t1.user_comment, t2. type , t2.object_type, t2.secure
from all_queues t1, all_queue_tables t2
where t1.owner:1 and t1.name:2 and t2.owner:3 and t1.queue_tablet2.queue_table 论坛条目可以在这里找到 。 尽管此查询在最新的驱动程序中得到了改进如错误报告所提及但它仍然导致数据库的大量开销。 解决此问题的两个选项 执行规范建议的操作将目标配置为应用程序服务器上的资源。 每次应用程序服务器都会分发相同的实例因此它们已经被缓存在那里。 即使您每次查找都会收到相同的实例但是在使用JndiTemplate或JndiDestinationResolver请参见下文时它也会在应用程序一侧被阻塞因此即使查找本身也只会发生一次。 在DefaultMessageListenerContainer上启用会话/消费者缓存。 将缓存设置为使用方时由于使用方持有对目标的引用因此它还会间接重用目标。 这个池是Spring添加的功能 JavaDoc说它在使用资源本地事务时是安全的而在使用XA事务时在JBoss 4上运行除外“应该”是安全的。 首先可能是最好的。 但是在我们的情况下所有目标均已在应用程序内定义并且有很多目标因此无需对其进行配置。 仅出于此技术原因而对它们进行重构将产生大量开销而没有其他优势。 第二种解决方案是最不受欢迎的解决方案因为这将意味着需要进行额外的测试和研究以确保没有任何问题。 同样这似乎还需要做更多因为在我们的案例中没有迹象表明创建会话或使用者对性能有可衡量的影响。 根据JMS规范 4.4 Session
A JMS Session is a single-threaded context* for producing and consuming
messages. Although it may allocate provider resources outside the Java virtual
machine, it is considered a lightweight JMS object. 顺便说一句; 这对于MessageConsumers / Producers也有效。 它们都绑定到一个会话因此如果一个会话轻量级可以打开那么这些对象也将打开。 但是还有第三种解决方案。 自定义的DestinationResolver。 DestinationResolver是负责从String到Destination的抽象。 缺省 DynamicDestinationResolver 在JMS会话上使用createConsumerjavax.jms.Destination进行转换但不会缓存生成的Destination。 但是如果将Destinations在应用程序服务器上配置为资源则可以除了使用Spring的JNDI支持并直接注入Destination之外还可以使用JndiDestinationResolver 。 该解析器会将提供的String视为JNDI位置而不是物理目标名称并为您执行查找。 默认情况下它将缓存生成的目标避免任何后续的JNDI查找。 现在还可以将JndiDestinationResolver配置为DynamicDestinationResolver的缓存装饰器。 如果将fallback设置为true它将首先尝试使用String作为从JNDI查找的位置如果失败它将使用JMS API将我们的String传递给DynamicDestinationResolver以将我们的String转换为Destination。 在这两种情况下都将生成的目标存储在缓存中因此将从缓存中为对同一目标的下一个请求提供服务。 使用此解析器可以直接使用一个解决方案而无需编写任何代码 bean idcachingDestinationResolver classorg.springframework.jms.support.destination.JndiDestinationResolverproperty namecache valuetrue/property namefallbackToDynamicDestination valuetrue/ /beanbean idinfra.abstractMessageListenerContainer classorg.springframework.jms.listener.DefaultMessageListenerContainer abstracttrueproperty namedestinationResolver refcachingDestinationResolver/.../bean 通过内部使用ConcurrentHasmap存储绑定JndiDestinationResolver是线程安全的。 根据JMS 1.1规范2.8多线程JMS目标本身就具有线程安全性并且可以安全地进行缓存 这再次是一个很好的例子说明简单的事情有时会产生重要的影响。 这次借助Spring解决方案非常简单。 但是最好将缓存行为设置为默认值因为这会使它与查找目的地的任何提供程序特定的怪癖脱钩。 这不是默认值的原因可能是因为DefaultMessageListenerContainer支持动态更改目的地 例如使用JMX Note: The destination may be replaced at runtime, with the listener container picking up the new destination immediately (works e.g. with DefaultMessageListenerContainer, as long as the cache level is less than CACHE_CONSUMER). However, this is considered advanced usage; use it with care! 参考 JMS和Spring小事情有时很重要 这是我们的JCG合作伙伴 Koen Serneels在技术博客上写的。 翻译自: https://www.javacodegeeks.com/2013/04/jms-and-spring-small-things-sometimes-matter.html
