Avoid timer overlapping in EJB schedule running inside wildfly

Question

I have an EJB timer schedule in a singleton EJB running inside a Wildfly 10.10:

@Singleton
@Startup
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class MySingletonBean {

    public method() {
        //uses synchronization primitives to fine control the concurrent access
    }

    @Schedule(hour = "*", minute = "*", second = "*", persistent = false)
    public void update() {
        //each 120 seconds update method timeouts and the overlapping/log message occurs
    }
}

The task inside the update() model runs smoothly spending less than 1 second mostly. However each 2 minutes, due the business needs, the method timeout spending more than 1 second.

The problem:

Each 2 minute wildfly outputs a log message like:

(EJB default - 1) WFLYEJB0043: A previous execution of timer [] is still in progress, skipping this overlapping scheduled execution at: .

It is clear for me what the message means: the previous timer did't finished before the next execution started and the overlapping occurs.

Further, the overlapping raises concurrent issues in the underly data structure under update.

My questions:

1 - How to discard the next schedule in the case when a timer is slow avoiding overlapping/concurrent update?

2 - How to avoid the log message if it is impossible do discard the overlapped schedule?

By the way, I thought about break the update method into two different schedules (1 sec and 120 secs). But break the update method implies over break off the whole data structure under updating, somehow complex and inviable at least for now.

Any help is appreciated!

Answer 1

What kind of bean is your "timer" bean? I think that making it a @Singleton could be enough for your case. If it will be a Singleton, there is no way to access the method by more than one thread.

Answer 2

I aggree with dgebert because the default ConcurrencyManagement is container-managed and default lock is write unless you have a cluster. in cluster every node has own singletone and lock managment. if you dont config a centeral database for timer service, all nodes will be executed and raises concurrent issues in the underly data structure.