-
1. Re: Blocking Ejb Call
wdfink Nov 5, 2010 3:29 AM (in response to schnabeltier)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
wolfc Nov 5, 2010 6:52 AM (in response to schnabeltier)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
schnabeltier Nov 5, 2010 7:49 AM (in response to wolfc)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
wdfink Nov 5, 2010 9:18 AM (in response to schnabeltier)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)