使用EJB Timer Service执行外部服务

Question

I have a scenario to ask regarding utilizing the EJB Timer Service.

Use case as follows: The system should be able to schedule a task that will poll/ask our subversion repository for files changes using some particular timestamp.

The idea is that whenever the scheduled task is about to run, it will execute command against a particular svn repository. For this particular purpose, I will not call any external process but will use the 'pure' java way of using the SVNKit java library http://svnkit.com/

My only concern is this: Is it a good idea to use the EJB Timer Service to execute task that will call external processes? My way will use a 'pure' java way but in other scenario such as calling a batch file/command line/external executable directly into the timer service logic.

I worry about the effects of server memory use/performance etc.

Is this a good idea?

The other thought that I am thinking is to just create a 'desktop' application in the server using client based technology such as SWT/Swing that will do the polling and then code the logic there but this will mean that I need to manage two applications. The 'desktop' app that will poll and the 'web' user interface that I will create in Glassfish.

I am leaning towards doing everything in the App server of my choice which is glassfish.

I have used EJB Timer before but it only calls against the database without calling any extenral service and it's just that this scenario came up so I raised a question here to gather more thoughts from those who have experienced doing this.

Any thoughts?

Answer 1

In theory, EJBs aren't supposed to depend on external I/O since it interferes with the container/server's management of bean instances, threads, etc.

In practice, this should work if you take precautions. For example:

• isolate the function to its own EJB (ie, a stateless session bean that only handles these timers) to avoid instance pooling issues
• use timeouts while waiting for commands to avoid hung processes from hanging all server threads
• ensure that you don't schedule timers so that you have multiple OS commands run simultaneously

Keep in mind that EJB 3.0 timers are persistent (vs EJB 3.1 timers, which have the option of being non-persistent), which means:

1. They can run on any server in a cluster. If you have multiple machines in your cluster, you need to ensure that they are all capable of running the command.
2. They survive server restarts. If you schedule a timer to run but the server crashes before it can, it will run when the server restarts. This can cause particular problems for interval timers (all missed timers will fire repeatedly) and if you don't carefully manage existing times (you can easily create redundant timers).