• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Timer and Cache in clustered env

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Lin Sun
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thoughts?
 
Ranch Hand
Posts: 497
2
Spring Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Do you know of anyone who has done this and been approved?
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 125
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Lin,

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.


Thanks,
Kumar.
 
reply
    Bookmark Topic Watch Topic
  • New Topic