CODEWITHSUNDEEP
multithreadingjakarta-eeconcurrencysingletonejb
serg
serg

Reputation: 1023

Thread.sleep() in EJB Singleton with the ConcurrencyManagementType.BEAN

Thread.sleep() in EJB bean considred as antipattern Thread.sleep() in an EJB, because "you should not create or manage threads"

But from EJB 3.1, there is Singleton for which we can define the ConcurrencyManagementType.BEAN. According to EJB spec:

With Bean Managed Concurrency demarcation, the container allows full concurrent access to the Singleton bean instance. It is the responsibility of the bean developer to guard its state as necessary against synchronization errors due to concurrent access. The bean developer is permitted to use the Java language level synchronization primitives such as synchronized and volatile for this purpose.

So if I want to implement method to wait one minute, could I use Thread.sleep() in such Singleton or maybe wait() with timeout, because it is synchronization primitive, or it is still will be considered as antipattern?

Upvotes: 1

Views: 1889

Answers (2)

Robert Panzer
Robert Panzer

Reputation: 1519

The EJB spec cites:

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

So the spec explicitely says to not call the methods start(), stop(), suspend() and resume(). It does not say anything regarding sleep() or wait() and I would say that it is an over-interpretation to think that these methods are forbidden too.

So sleep() should work without problems and with bean managed concurrency it will be even possible to not block other threads. Nevertheless I am wondering why you need to sleep, but that's a different question.

For wait() you need a synchronized block with a monitor and depending on what object you choose you might block other threads. It may be the case that you want to have mutual exclusive code or not, that is up to your use case.

With container managed concurreny both sleep() as well as wait() will block other threads for the sleep time.

Upvotes: 1

Dejan Paler
Dejan Paler

Reputation: 21

EJB 3.1 specification says:

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enter- prise bean must not attempt to manage thread groups.

With Thread.sleep() you would still break the above rule even if bean is annotated with ConcurrencyManagementType.BEAN.

Thread.sleep() could be used in managed thread by injecting managed executor service. Something like this:

    @Stateless
    public class ManagedThread {

    @Resource
    ManagedExecutorService executor;

        public void executeManagedThread(){
            Runnable task = () -> {
                try {
                    // some long running task
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            };
            executor.execute(task);
        }

    }

ConcurrencyManagementType.BEAN is useful for managing concurrent access in your singleton bean. For example concurrent access differs in reading and writing to some resource. More info can be found here http://docs.oracle.com/javaee/6/tutorial/doc/gipvi.html.

Upvotes: 1

Related Questions