This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
For my JEA 5 part II assignment, I'm designing a Timer Service to periodically invoke a SLSB to pull information from DB and send JMS message to external system. When external system responds, the response triggers MDB to populate a Cache (singleton POJO) in business tier. Another SLSB will consume data in Cache and send to web tier for presentation.
For scalability I'd like to have business tier in a clustered env (two app servers). The concern I have is each server/JVM may create a separate Timer Service and Cache thus the consequence may be:
1. Each Timer Service may invoke SLSB to send JMS message causing redundant message in queue.
2. Multiple copies of Cache. One in each JVM.
To get around the first issue I'm thinking about having a turntable in DB for the invoked SLSB to check if it is its turn to send JMS message. The turntable will have each deployed server id and some round robin logic.
Not sure how to get around the second issue other than deploying the Timer Service and Cache to a separate server (a third instance). But that presents a single point of failure which defeats the purpose of cluster.
Putting data in DB may solve both issues but the Cache is there to avoid having to access DB with assumption that I/O is more expensive than RMI.
Any suggestions on how to design a simple solution?
Joined: Mar 23, 2012
Another way to look at the problem: Since there are AS products (i.e. weblogic or glassfish) supporting EJB Timer in clustered environment. Can I simply make an assumption that AS to be purchased will support this feature via configuration so that duplicated invocation will be prevented. And then I don't have to worry about it when drawing all the diagrams.
To collect data from the DB and send to the external system, how about this idea?
1. Write a simple standalone Java program that will pull information from the DB and send a JMS message (via JMS API) to the Queue.
2. Schedule the above process as a CRON job in ONE of the servers. You can set any period you like.
The cron job will invoke the Java process and keep sending JMS messages to the external system. With this you don't need to worry about synhronizing data between machines
Once the response is received from the external system, the process you outlined looks fine.
Application servers will take care of the EJB Timers in cluster environment OR you can provide solution in terms of HTTP Session Replication of cluster environment supported by most of the application servers. If both DB and Cluster environment ways of handling the situation is fine.
In assumptions list if these are provided its enough.