Details
Description
>If you have specific requirements on this chapter or wish >some samples please let us know.
Yes, if you have some examples of Esper running in an EJB container I would be very interested. Our use case is the following: We have an J2EE-based self-service terminal managing system, which gets a lot of events from connected
terminals (500 per second; e.g. ´paper low´, ´terminal out of order´) and we are correlating these events in the server to build up higher-level events. So for us it would be nice to use Esper in conjunction with our framework which is based mostly on stateless session beans and JMS messaging.
>Esper is light-weight in terms of threads: each engine
>instances starts 1 timer thread. However the engine can
>also be externally timed and the timer thread disabled.
>Thus Esper
>engine threading should not interfere with J2EE
>container threading.
Sounds perfect. I think it is very important that Esper is fully J2EE compliant and not specific to any AppServer, so that it can be used in many scenarios and big applications.
>Esper engine instances are not clusterable. That is, engine
>state cannot be replicated within a J2EE application server
>cluster if your server supports this configuration.
No problem in a stateless application using JMS persistence.
>If you are running inside an EJB container, using stateless
>session EJBs, pooled EJB instances would need to share the
>same Esper engine instance. The mechanism for sharing an
>engine instance between EJBs, I think, would have to be via >static member variable, Singleton or possibly JNDI. For
>servlets, the servlet context would seem to suit.
An example of SLSBs using the Esper engine instance would be nice.
New terminal service case study added