0

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?

Mark Estrada
  • 9,013
  • 37
  • 119
  • 186
  • ive been implementing the 2nd aprouch with desktop app and have a scheduled task send messages using jms. the reason being that the desktop app will run on connected clients. this works okay, the issues ive been running into is about deployment of the client app, which is an area in itself. So if you never will have the requirement to run on a different machine, i dont think it is worth the cost – Aksel Willgert Oct 22 '12 at 06:16

1 Answers1

3

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 (i.e., 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).
Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • 1
    Hi excellent thoughts. On the other hand,will creating a Singleton EJB and the @Startup plus the schedule expression will fixed the problem you stated above? I was thinking that since it is Singleton and will fire during deployment I would be able to fix the problem you stated above. Thanks – Mark Estrada Oct 23 '12 at 05:42
  • You used the ejb-3.0 tag (vs ejb-3.1), so I didn't know if you could use EJB 3.1 features. Yes, using an `@Singleton` solves many of the problems, and if you use `@Schedule(persistent=false)` (with time attributes, obviously), you don't even need `@Startup`. – Brett Kail Oct 23 '12 at 15:37
  • Thanks... I can used anything actually.. as for the EJB 3.0 or EJB 3.1, I am not sure about this as I am still a learner when it comes to EJB. But thanks to your thoughts I will make use of the @Singleton annotation plus the Schedule removing the StartUp. – Mark Estrada Oct 24 '12 at 01:59