Are interceptors similar to EJBs?

    Being inspired by the blog entry and my current activity at work, I decided to present the behaviour of interceptors. Do they share something more with EJBs? Let's check it out!

I created two simple artifacts:

1).  interceptor:

2). stateless session bean:

 

I put the handling thread to sleep in order to simulate long running transaction or intensive computations. Note that thread manipulation within EJBs is not allowed, however for testing purposes it is acceptable :).

Next, I performed 3 serial invocations (one after other) of the 'interceptedMethod()' - it is exposed via REST so I was able to hit it with regular GET request. The result:

It looks pretty straightforward. We have one request, one thread is dispatched to handle it and two objects from our code are involved. After that, I performed 3 parallel requests:

Three parallel requests resulted in 3 threads and 6 objects. On the basis of the presented analysis it can be stated that interceptors are thread safe. They are similar to EJBs in the way in which they achieve thread safety. When there is a request, the container picks an interceptor instance up from the pool to handle that request. When the requests are serial - one instance is enough to handle them. However, when there are multiple parallel requests - more instances are involved. Despite the fact that multiple threads work in parallel, they operate on different instances so there are no problems with thread safety unless we use static variables. EJBs share this feature with their interceptors.