1

Could someone suggest what’s the best approach to go about this:

What I like to do is draw a continuous poll (or query) of a database table. And anytime a new update has occurred, I want to push this to the client in a Java application. The idea is users can suggest what data they want to subscribe to and define an event-handler to handle any incoming data.

I therefore need to have the polling being done in the background. But I seem to having trouble with doing this correctly. I’m looking at using a simple event bus for local JVM pub/sub, but I can’t seem to get the asynchronous continuous polling going.

Larry
  • 11,439
  • 15
  • 61
  • 84
  • 1
    What user interface? Swing or web? – Jonas Jul 24 '11 at 15:44
  • Are you using a `Timer`? – toto2 Jul 24 '11 at 15:47
  • @Jonas At the moment it is just a Java library. Where I want users to define an event-handler to handle events they want to subscribe to. On the publishing side, new entries in the table act as events coming in. – Larry Jul 24 '11 at 15:50
  • @Larry see for example [this](http://enos.itcollege.ee/~jpoial/docs/tutorial/essential/threads/timer.html). – toto2 Jul 24 '11 at 15:54
  • @toto What’s the differences between this and what jiggy suggested below (i.e using a ScheduledThreadPollExecutor)? – Larry Jul 24 '11 at 16:00
  • @toto, Assuming he is 1.5 or up, [executors are preferable to timers](http://stackoverflow.com/questions/409932/java-timer-vs-executorservice). – jiggy Jul 24 '11 at 16:03
  • @jiggy OK, I agree that ScheduledThreadPollExecutor's are better. – toto2 Jul 24 '11 at 16:06

2 Answers2

2

Your solution has a lot of disadvantages.
A better solution is to create business logic that is responsible for saving data in the database and for notifications. You can for example create an application that is subscribed to JMS topic. Another component receives calls to process and save data. It stores data and then sends notification of this action. All components subscribed to the topic receive this notification and react accordingly.

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
AlexR
  • 114,158
  • 16
  • 130
  • 208
  • That'a assuming his app is also responsible for populating the data. – jiggy Jul 24 '11 at 15:52
  • Thanks, but JMS seems too complicated to implement. Is there a more simple solution? That is why I was thinking of a simple ESB like http://code.google.com/p/simpleeventbus/, but I’m stuck trying to get a continuos poll/read of the DB? – Larry Jul 24 '11 at 15:52
  • @jiggy That is right, populating the Data happens via a different app. I am aiming for this to be a client-side application connected to the DB to get events, via new entries in the DB table. – Larry Jul 24 '11 at 15:54
1

Have a look at java.util.concurrent. You can create a scheduler to run at a given interval utilizing a thread pool like with a ScheduledThreadPoolExecutor.

jiggy
  • 3,828
  • 1
  • 25
  • 40
  • thanks, do you happen to know of any good examples/sample code on the web for this? – Larry Jul 24 '11 at 15:56
  • @Larry, just look a this [javadoc](http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ScheduledExecutorService.html) for a good example of a scheduled job. Instead of beeping, you can read your DB. Note that the `Runnable` class is defined inline for terseness, but it can be defined in it's own .java file and just instantiated here. – jiggy Jul 24 '11 at 16:00