Infinite loop with thread sleep vs EJB 3.1 Timers in WebSphere 8: backpressure

Question

I have a requirement to

• read a Database table
• process the data (dataCleanser)

to, increase the throughput, I implemented EJB timers (non persistent) that wake up every 5 minutes (10 of them) and do the above work.

The problem is 'back pressure', the dataCleanser can sometimes take like 12 minutes (makes an external API call) and when this happens, Websphere reports a hung thread.

In those cases, I would like to decrease the number of timers (say from 10 to 5) programatically. I can do that only if the timer comes back reports its status of successful execution or exception or timeout

that way I can control the back pressure. is there anyway to do that in Websphere 8?

To ask the question in another way

- can the EJB timers(with transaction_not_supported) invoke another EJB that have transaction timeouts? - can those timeouts be caught in the calling timer code?

if that is not possible, what are the downsides of using the plain old infinite loop with sleep and then invoke and EJB(in turn calls dataCleanser) with transaction timeout?

one of the downside, I know is this becomes single threaded and I do not how to make 10 parallel executions like I would do with timers.

Answer 1

I had some similar issues with scheduling, I decided to re-schedule callbacks programmatically each time my logic ended, based on the results of processing. You can have the timer service injected:

@Resource
private TimerService timerService;

This can be in a superclass if there are multiple EJBs that need scheduling, with methods like:

protected void reschedule(long millis) {
    timerService.createTimer(millis, null);
}

This way you can control beans individually. I would not try to make them control each other, since that would become difficult in a cluster with multiple JVMs.