I'm writing a service that will call REST service every x seconds. I could do that with EJB #Schedule annotation as well as with ScheduledExecutorService.
which one is better to use? and why?
If you're writing an EJB application, you should use Schedule - the EJB spec demands that EJBs should not use threads directly, and says that doing so may cause errors in the container, as well as preventing the container from managing resources efficiently.
In exchange, with Schedule you get the benefits of container management and EJB services.
Related
Im am currently having issues with injection of EJBs in a thread. WildFly, Websphere Liberty >17 and even WebSphere Traditional >9 can deal with injection of EJBs in Threads, but in WebSphere Traditional 8.5 I am experiencing a NullPointerException in ResourceInjectionServiceImpl.
The JavaEE Specification says that there should be no Threads started in Beans, but not that there should be no injection in "manually created Threads". InjectionTarget is used to inject the EJBs and the created instances (after injection) are passed to an ExecutorService instance.
My question: Is there a way to get this also working in Websphere Traditional 8.5?
No, there is no way to do injection into manually created threads, mainly because you should not being doing that, as stated repetedly in the Java EE specification. You definitely should not be creating threads with EJBs, you're almost assured to have memory leaks, lock up your database pools, locking the transaction managers, among many other very common bugs.
Fortunately, if you need concurrency, you have a lot of options. The simplest is to use the #Asnycronous annotation. A robust solution is to use JMS and go fully asynchronous. Another option is to inject a ManagedExecutorService and submit tasks to it. Finally, very poor mans concurrency can be had with the Java EE Timer API.
All of these are fully supported and will not cause issues when used properly. However, creating threads is not supported in Java EE and forcing it to work will only create headaches for you later.
You may want to use ManagedExecutorService which can be obtained through the resource injection. It gives you the capability to execute your tasks in server managed thread pool. Therefore, beans created in service threads can be used in worker threads and vice-versa.
#Resource //(lookup="java:comp/DefaultManagedExecutorService")
ManagedExecutorService managedExecutorService;
I have a Java EE app that's deployed on WildFly AS.
I have a method annotated with #Asynchronous and I need to set the max number of threads for this method.
I configured a new <managed-executor-service> in server config, but I don't know how to bind it to an async method.
This link: https://developer.jboss.org/message/851027#851027
provides a good answer to how (or when) to use #Asynchronous and when to use JSR-236 ExecutorService and concurrency utilities:
In short, #Asynchronous is a annotation (EE6) to mark an EJB method as async.
You can invoke the method and keep the future object to check whether the method is finished and get the result. The EJB Concurrency Utilities are provided to have a safe way in EE7 to delegate work to a parallel thread. Threads started by this ConcurrentUtilities are managed by the container.
In difference to a direct start of a Thread (which is not allowed for an EE application). There is less overhead than using #Async and you have a bit more control.
See also this link about how to inject a MES:
http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_with_java
I have been reading lately about safe publication of Java objects (e.g. here: http://shipilev.net/blog/2014/safe-public-construction/).
Until now I was trusting EJB container without questions when relying on container managed concurrency.
Now I'm wondering
1) how an EJB container can make sure that the EJB itself is published safely?
2) how an EJB container can make sure that objects created by its EJBs are published safely (e.g. EJB instance vars)?
E.g. stateless session bean can be accessed by different threads over time (I'm not necesseraly saying simultaneously), so unsafe publication is a potential issue.
For 1), I roughly see possibilities, e.g. by wrapping the EJB and using some volatile accesses to garantuee total order.
For 2), I don't see how EJB container can enforce it.
Maybe it is forbidden by the EJB 3.1 spec to keep instance variables in the EJB if it can be accessed by different threads?
Maybe the statement "don't worry about concurrency in container managed EJB" is not true, and I should use safe publication patterns (including volatile and/or final keywords) in the class definitions of the classes used in my EJB instance vars?
I'm surpirsed I missed this fundamental problemacy for that many years as a Java developer.
Regards,
Lars
If an EJB container is reusing instances, it must store them in a thread-safe object pool, which must use some synchronization (synchronized, compare-and-swap, etc.), which will ensure that everything written by the first thread will "happen-before" everything that happens on the second thread. EJB developers do not need to worry about synchronization (unless they're using singleton session beans with bean-managed concurrency or the EJB is going outside the scope of the EJB spec by storing data in static variables).
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.
I have a process that I want to run serially, but in a different thread. How can I accomplish that in JBoss 7? The obvious answer would be an #Asyncronous EJB method where the EJB is configured to only have one thread running at a time (the others requests would be in queue).
How can that be best accomplished?
I believe a great way of achieving this is using a combination of Singleton + Asynchronous annotations from EJB 3.1, you can also use the AccessTimeout annotation to provide wait timeout for the queued calls and finally you can even use Lock annotation to control READ,WRITE locking on this if you want:
#Singleton
public class SingletonAsyncProcessor{
#Asynchronous
#AccessTimeout(5000) //times out after 5 seconds
public Future<String> addJobToQueue(String jobName) {
Also notice that you can use most of these annotations at class level(all methods will be async) or method level. You can even run EJB 3.1 in the web container.
EJB 3.1 ROCKS.
Regards.