0

As @Balus has explained in Spawning threads in a JSF managed bean for scheduled tasks using a timer

EJB available? Use @Schedule If you target Java EE 6 or newer (e.g. JBoss AS, GlassFish, TomEE, etc and thus not a barebones JSP/Servlet container such as Tomcat), then use a @Singleton EJB with a @Schedule method instead. This way the container will worry itself about pooling and destroying threads via ScheduledExecutorService.

So i am curious to know by using @Schedule, the background process will run asynchronously by container managed threads (magically) or it is like a java.util.timer which creates single thread and all process run within this threads??

if @Schedule creates only single thread just to manage the scheduler then would it be safe to use further ScheduledExecutorService within @Schedule? and this ScheduledExecutorService contains further runnable tasks based on multiple threads.

I have a long running process including file manipulation, data processing and email generating, but really should i rely only on this single @Schedule annotation without using any executorservices/creating further threadpool?? BTW i am using Glassfish.

Community
  • 1
  • 1
umaair_653
  • 103
  • 10
  • As far as wildfly is concerned, it has a pool of workers to execute schedulers. If you perform a log inside your scheduled method, you will notice that the thread ids changes in every execution – maress Feb 23 '17 at 09:47
  • This in theory is forbidden by the EJB specification: "I have a long running process including file manipulation" infact from the spec : "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system." – Leonardo Feb 23 '17 at 10:01
  • @Leonardo then what is the preferable way to file manipulation etc file read, folder move etc? I have done these loggic within runnable class which is further used by ScheduledExecutorService within Schedule method. – umaair_653 Feb 23 '17 at 10:59
  • This is why the [batch processing API](http://docs.oracle.com/javaee/7/api/javax/batch/api/package-summary.html) exists – Steve C Feb 23 '17 at 11:25
  • 2
    If you use a Singleton SessionBean, the container will manage concurrency and with default settings, any timer (obtained with javax.ejb.Schedule annotation) will wait until the previous one has ended and you'll be guaranteed that the concurrent access is managed (or in this case prevented) by the container. See https://docs.oracle.com/cd/E19798-01/821-1841/gipsz/index.html – perissf Feb 27 '17 at 10:06
  • @perissf so it doesn't make sense to start further scheduledExecutorService from Scheduler annotated method for long running process?? and what about the **exceptions** if due to some reason the next iteration doesn't start? i didn't find any exception handling for EJB schedule on internet. – umaair_653 Feb 27 '17 at 10:32
  • 1
    Can't answer about scheduledExecutors, but regarding exception in the execution of timer services, they are noisy but should never kill the Singleton SessionBean. See http://stackoverflow.com/questions/14402068/ejb-schedule-wait-until-method-completed – perissf Feb 27 '17 at 11:01

0 Answers0