让bean使用CDI bean（使用Myfaces CODI）代替JSF托管bean已有一段时间了，我一直在阅读一些教程，以便更好地理解我可以真正做什么技术。最明显的利用潜力是CDI事件模型，但我没有太多灵感可以用于它。
我有一个页面计数器机制，它可以维护页面访问的持久记录，而无需访问关键路径上的数据库，即减慢页面加载时间。这通过在AtomicReference访问的ConcurrentHashMap中递增AtomicInteger来实现，数据存储在单例EJB中。然后，EJB计时器定期“抓取”映射，将其替换为新映射，并将新命中添加到相应的数据库记录中。 PreDestroy侦听器会在应用服务器关闭时保存所有非持久更新。
我认为在页面加载时我可以用一个应用程序范围的CDI bean发出“页面访问”事件来观察它并进行后端处理，但这在某些方面不符合现有设计：
目前批量更新，计时器方法每隔几分钟就会运行一次。
虽然如果服务器电源出现故障，现有设计将丢失数据，但这是不可取的但可以接受，但它处理正常关机时相当可靠。
我需要更好地了解在服务器关闭的情况下排队的CDI事件会发生什么，我将通过规范来解决这个问题。
虽然我很欣赏任何有关上述想法的反馈，但我真正感兴趣的是受到在JSF应用程序中使用CDI事件的任何有趣场景的启发，有谁愿意分享他们的经历？
感谢。
答案 0 :(得分：3)
您可以在jsf应用程序中的以下用例中使用CDI事件：
对于您的用例，您可以使用@Asynchronous注释负责存储页面视图统计信息的EJB，以便在另一个线程中执行此操作。那么我认为你的页面加载不会减慢。
通常，当您想要使用旧的事件/观察者模式但是以分离和优雅的方式加上DI功能时，您可以使用CDI事件。这种模式可以应用于各种各样的用例。
答案 1 :(得分：1)
首先事件是同步的，而非异步。这意味着你显然不能像JMS那样使用它们，如果服务器停止，就没有像故障转移这样的东西了。
事实上，唯一的原因 - 我知道 - 为什么引入事件机制是以类型安全的方式解耦组件（但这是一个很好的理由：）
我遇到的最优雅的场景之一是Seam Catch（现已成型为 Seam Solder ）。在此处查看this说明。 事件驱动的异常处理的想法是允许不同的参与者（又名：CDI模块和用户代码）注册自己以进行异常通知。然后，该事件在注册观察者链中上下起伏，并将使用固有的CDI机制自动找到最合适的处理程序。
如果您阅读文档/最好自己查看源代码，那么