Java EE : Creating and deleting socket listeners dynamically from the domain model

Question

我正在创建一个 Java EE 应用程序，允许用户从 Web 界面添加/删除“socketinfo”表(存储在数据库中)。如果用户从 Web 界面启用“socketinfo”，应用程序服务器必须为传入的数据包创建一个套接字监听器并处理数据。如果用户禁用或删除“socketinfo”，则必须删除套接字监听器。整个产品必须包含在一个耳朵中，并且最好是合规的。我考虑过但遇到问题的一些方法是:

1. 为套接字创建 JCA 资源适配器并使用 MDB 作为监听器。我在这里遇到的问题是，当用户添加 MDB 时，我无法弄清楚如何以编程方式为不同的套接字部署 MDB。

2. 创建一个 @Singleton/@Service ejb 来管理守护线程并仔细同步。可以将单例 ejb 注入(inject)业务层，以便在正确的工作流中进行 CRUD 操作和套接字操作。这里的问题是，据称从 EJB 创建线程被认为是一种不好的做法，并且不符合规范(即使单例生命周期得到正确处理并且适当的同步机制已经到位？)。

3. 将线程放入域模型(另一个单例？)并让 EJB 使用该模型。这是所有这些中最糟糕的，因为应用程序服务器往往有多个类加载器，一般来说容器支持较少，而且这会带来所有问题 2. 问题。

知道如何在 Java EE 中正确处理这种情况吗？

编辑:这个问题的扩展:假设我决定像 ewernli 在他的解决方案 3 中建议的那样解决这个问题，那么在 JCA 中这样做(使用自定义接口(interface)来添加内部线程)我会得到什么，我不会得到来自(精心设计的)单例？虽然创建资源适配器看起来不像是一项艰巨的任务，但它似乎并不完全微不足道并且可能会耗费一些时间(对于其他开发人员来说可能更难遵循)。

Answer 1

您的分析似乎是合理的，您说的不能动态部署 MDB 以适应 JCA 是正确的。

更多的设计思路:

• 您可以编写一个返回 SocketConnections 的 JCA 连接器(本着 JMS 的精神)，您可以使用它从套接字中读取数据。继续 JMS 类比，MDB 代表 MessageListener，而您要公开的是 MessageConsumer。

• 您可以使用周期性计时器来模拟线程。与带有 while 循环的线程不同，您有一个可以重新安排自身时间的计时器。我将它用于一个应用程序，使其具有后台进程，并且效果很好。请注意，我还直接从 EJB 生成线程以在另一个应用程序中执行一些并发计算，并且效果也很好。但是短命的线程和bean中的业务方法会一直等到全部完成，所以这不是对规范的重大违反。

• 另一种设计是让 JCA 连接器处理线程等，并将所有消息传递给 MDB。 MDB 将接收数据，以及有关数据对应的“ channel ”的信息，例如套接字端口。这就像在一个 MDB 中进行多路复用，然后对数据进行多路分解。您的连接器可以提供额外的 API 来控制线程的创建等，并且可以将此接口(interface)注入(inject)到您的 EJB 中(类似于 ConnectionFactory)。您的连接器可以提供额外的 API 来控制线程的创建等。不是很清楚，但我希望您能理解。如果我是对的，JCA 连接器可以确保将数据同步传送到 MDB，至少是每个套接字，以便 MDB 以正确的顺序处理数据。

如果开发时间允许，我会选择 #3，。

编辑

这种选择确实在一定程度上是设计纯度的问题。用户生成线程的一个问题是您显然不能对它们使用声明式事务。不过，您也许可以使用 UserTransaction 自己划分事务。我不知道您在这样的线程中使用 EntityManager 的效果如何。如果您主要处理数据并且不使用中间件的很多功能，则可以自己生成线程。看我的另一个回答:How can an EJB parallelize a long, CPU intensive process? .我想到的其他事情(不知道它们是否有问题):安全管理器可能会阻止创建线程(？)，而不是将它们创建为 deamon threads可能会阻止该应用程序。服务器正确关闭(？)。请注意，我在启动时从 ServeletContextListener 生成了线程，而且效果很好。这是一个经常使用的技巧，即使它违反了规范。对于"new"引入的单例 bean，情况可能也是如此。所以，如果你时间不够，你当然可以用一个单例 bean 来尝试你的提议，看看什么有效/无效。