4 Replies Latest reply on Nov 5, 2010 9:18 AM by Wolf-Dieter Fink

    Blocking Ejb Call

    qqq qqqq Newbie



      there is a discussion in our team, wether blocking a ejb call

      in the ejb method using a BlockingQueue is a problem or not.


      What is your opinion?

        • 1. Re: Blocking Ejb Call
          Wolf-Dieter Fink Master

          IMHO blocking EJB sounds like thread-influence and should be avoided.

          It will have a significant influence to scalability and might make the application server unstable.


          You should think about what is the behaviour you want and look/think for other solutions.

          If it works for you it might be ok even if you break the JEE spec.

          But you must test it very well!

          • 2. Re: Blocking Ejb Call
            Carlo de Wolf Master

            It's not a problem, it's a risk.


            The whole point of the EJB specification is to reduce risk and have a predictable component.


            EJB 3.1 FR Introduction:

            Applications written using the Enterprise JavaBeans architecture are [...] multi-user secure.


            You can always ignore the specification and take care of ensuring this yourself. And I agree complete with Wolf-Dieter:


            Wolf-Dieter Fink wrote:


            But you must test it very well!


            Note that for example a call to a database is also blocking, so the blocking itself is not something that's unexpected.


            What is your use case? Who feeds the queue? Why not use MDB?

            • 3. Re: Blocking Ejb Call
              qqq qqqq Newbie

              Sorry, there are collegues who think blocking is not a problem - when

              let' s say 10 threads are blocked, just increase the number of allowed threads of the pool.

              • 4. Re: Blocking Ejb Call
                Wolf-Dieter Fink Master

                Your collegues should think about clustering.

                What about BlockingQueue in a clustered environment? Are you really sure that this will work over JVM or system border


                This is the reason why JEE require that you do not have to use environment (java.io, thread control ...) this is the responsibility of the application container.


                Often this kind of solutions must be refactored if JBoss version changed, migrate to a different server or if requirement change (e.g. clustering)