我正在尝试利用.NET Kaazing客户端，以便通过Web套接字与JMS后端进行交互。我很难理解会话的正确用法。最初，我在所有线程中共享了一个会话，但我注意到这是not supported：
Session对象是用于生成和使用消息的单线程上下文。虽然它可以在Java虚拟机（JVM）之外分配提供程序资源，但它被视为轻量级JMS对象。
我参加一次会议的原因只是因为我认为会产生更好的表现。由于文档声称会话是轻量级的，我毫不犹豫地将代码转换为每个“操作”使用一个会话。 “操作”是指发送单个消息或订阅队列/主题。在前一种情况下，会话是短暂的，并在发送消息后立即关闭。在后一种情况下，只要订阅处于活动状态，会话就需要存在。
当我尝试创建多个会话时出现错误：
System.NotSupportedException: Only one non-transacted session can be active at a time
谷歌搜索此错误是徒劳的，所以我尝试切换到交易会话。但是在尝试创建消费者时，我得到了一个不同的错误：
System.NotSupportedException: This operation is not supported in transacted sessions
所以看来我被困在一块岩石和一块坚硬的地方之间。我看到的唯一可能的选项是跨线程共享我的会话，或者用于创建消费者的单个非事务会话，以及其他所有事务的多个事务会话。这些方法对我来说似乎有点不利。
有人能说明我在客户端处理会话的正确方法吗？
答案 0 :(得分：0)
有几种方法可以为应用程序添加并发性。您可以使用多个Connections，但由于网络开销增加，这可能是不可取的。更好的方法是通过调度Tasks或通过ConcurrentQueues传递消息来实现一个简单的机制来处理Message Listener中的并发。以下是实施策略的一些选择：
基于任务的方法将使用TaskScheduler。在MessageListener中，将安排一个任务来处理工作并立即返回。例如，您可以为每条消息安排一个新任务。此时，MessageListener将返回，下一条消息将立即可用。这种方法适用于低吞吐量应用 - 例如每秒几条消息 - 但是你需要并发的地方可能是因为某些消息可能需要很长时间才能处理。
另一种方法是使用消息的数据结构来处理待处理的工作（ConcurrentQueue）。调用MessageListener时，每个Message都将添加到ConcurrentQueue并立即返回。然后，一组单独的线程/任务可以使用适合您应用程序的策略从ConcurrectQueue中提取消息。这适用于更高性能的应用程序。
这种方法的一种变体是为每个处理入站消息的Thread提供ConcurrentQueue。这里MessageListener不会管理自己的ConcurrentQueue，而是将消息传递给与每个线程关联的ConcurrentQueue。例如，如果您有表示股票供稿和新闻订阅源的入站消息，则一个线程（或一组线程）可以处理股票供稿消息，另一个线程可以单独处理入站新闻项。
请注意，如果您使用的是JMS队列，则在MessageListener返回时，将隐式确认每条消息。这可能是您希望申请的行为，也可能不是。
对于性能更高的应用程序，您应该考虑方法2和3。