1

I did an application to do some testing on network nodes like ping test, retrieve disk space ans so on.

I use a scheduled batchlet to run the actions but I wonder if it is the rigth use of batchlet?

Does an EJB timer should be more relevant? Also, when I run a batchlet, my glassfish server keeps a log of the batch job and I don't necessary need it (especially with the amount of batch jobs genereted during a day).

If I need to run some job in the same schedule time, I think batchled can do it but EJB timer too?

Could you give me your input on the rigth way to achieve this?

Thanks, Ersch

Ersch
  • 173
  • 2
  • 15

2 Answers2

1

Using an EJB timer is appropriate when your task executes in an eye blink (or thereabouts).

Otherwise use the batching mechanism.

Long running tasks executed from EJB timers can be problematical because they execute in transactions which normally time out after a short period of time. Increasing this transaction time out also increases the chances of database and perhaps other resource locks which can impact normal operation of your application.

Steve C
  • 18,876
  • 5
  • 34
  • 37
1

This isn't a question with a clear answer, but there is a bit of a cost in factoring your application as a batch job, and I would look at what I'm getting to see if it's worth doing so.

So you're thinking about a job consisting of a single Batchlet step. Well, there'd be nothing gained from "restart" functions, neither at the failing step within a job nor leveraging checkpoints within a chunk step. The batchlet programming model is quite simple... even if you really like @BatchProperty you'd have to deal with an XML now to do so.

This only starts to get more interesting if you want to start, view, and manage these executions along with the rest of your batch jobs. This might be because you're working with an implementation that offers some kind of implementation-specific add-on function. An example of this could be an integration with external scheduler software, allowing jobs to be scheduled by it. At the other extreme, if you found value in having a persisted record of all your batch job executions in one place (the job repository, usually a persistent DB), then that could also make this worthwhile for you.

But if you don't care for any of that, then an EJB timer could be the way to go instead.

Scott Kurz
  • 4,985
  • 1
  • 18
  • 40
  • I don't really need to have a validate or a check if the job has been completed properly. The only thing I want to do is look if a node is alive and generate an alert in my application if it is not alive. In the case of a disk space check, create an alerte if the free space trigger is reached. I did an implementation of the fonction in an EJB but, I had some performance issue during when the tesing ran. It was the reason why I looked to have the batchlet in the background. As it is a "end of study" work I need to do many code as possible by miself, hope it helps to identify my need. – Ersch Apr 20 '17 at 21:28
  • Doesn't seem obvious why the batchlet would avoid a performance issue that a timer would hit. Well, good luck. – Scott Kurz Apr 22 '17 at 14:16
  • Probably I had a bad use of the EJB, I directly called the method to check the nodes status to render my jsf page so during the run of the method my page was freeze. Also, it is possible to have some batches who run in the time but I wonder if we can do it via EJB timer – Ersch Apr 22 '17 at 14:24