3
votes

Having bean using CDI beans (with Myfaces CODI) in place of JSF managed beans for some time I've been going through some tutorials to get a better understanding of what I can really do with this technology. The most obvious potential for exploitation is the CDI event model but I don't have a lot of inspiration for what I can use it for.

I have a page counter mechanism which maintains a persistent record of page accesses without accessing the database on the critical path, i.e. slowing down the page load time. This works by incrementing an AtomicInteger in a ConcurrentHashMap accessed by an AtomicReference, with the data stored in a singleton EJB. Then an EJB timer periodically "grabs" the map, replacing it with a new one, and adds the new hits to the appropriate database record. A PreDestroy listener saves any non-persisted updates on app server shutdown.

I thought that on page load I could just fire a "page access" event with an application scoped CDI bean observing it and doing the back end processing, but this falls short of the existing design in a few ways:

  • at present the updates are batched up, the timer method runs only every few minutes.

  • while the existing design will lose data if there's a server power failure this is not desirable but acceptable, but it's reasonably reliable in that it handles graceful shutdowns.

I need a better understanding of what happens to queued CDI events in the event of, say a server shutdown and I will go through the spec to figure this out.

Whilst I'd appreciate any feedback on the above idea what I'm really interested in is being inspired by any interesting scenarios where you use CDI events in a JSF application, anyone care to share their experiences?

Thanks.

2

2 Answers

3
votes

You can use CDI events in following usecases in a jsf application:

  • fire/observe events when user wants to login/logout
  • fire/observe events when user changes locale
  • fire/observe events when user changes theme
  • etc.

For your use case, you can annotate the EJB that is responsible to store page view statistics with @Asynchronous to do it in another thread. then I think your page load won't slow down.

Generally you can Use CDI events when you want to use old Event/Observer pattern but in decoupled and elegant way plus DI features. And this pattern can be applied to wide variety of usecases.

For more info read this blog too. link1 link2

1
votes

First of all events are synchronous, not asynchronous. This means that you obviously cannot use them like JMS, and there is nothing like a fail-over if the server stops.

In fact the one and only reasons - I'm aware of - why the event mechanism has been introduced is for decoupling components in a typesafe way (but that's a pretty good reason :)

One of the most elegant scenarios I've came across is Seam Catch (now molded into Seam Solder). Check out this description here. The idea of that event-driven exception handling is to allow different participants (aka: CDI modules and user code) to register themselves for exception notification. The event then bubbles up and down the chain of registered observers and will use inherent CDI-mechanisms to automagically find the most appropriate handler.

Best if you read the documentation / check out the source code for yourself.