How to start a background Process in j2ee

Question

Hi

I want to start a background process in a j2ee (OC4J 10) envronment. It seems wron to just start a Thread with "new Thread" But I can't find a good way for this.

Using a JMS queue is difficult in my special case, since my parameters for this method call are not serializable.

I also thought about using a onTimeout Timer Method on a session bean but this does not allow me to pass parameters (as far as I know).

Is there any "canon" way to handle such a task, or do I just have to revert to "new Thread" or a java.concurrent.ThreadPool

Thanks

Peter

Answer 1

Don't know OCJ4 in detail but I used the Thread approach and a java.util.Timer approach to perform some task in a Tomcat based application. In Java 5+ there is an option to use one of the Executor services (Sheduled, Priority).

I don't know about the onTimeout but you could pass parameters around in the session itself, the app context or in a static variable (discouraged would some say). But the name tells me it is invoked when the user's session times out and you want to do some cleanup.

Answer 2

J2EE usually attempts to removing threading from the developers concerns. (It's success at this is a completely different topic).

JMS is clearly the preferred approach to handle this.

With most parameters, you have the option of forcing or faking serialization, even if they aren't serializable by default. Depending on the data, consider wrapping it in a serializable object that can reload the data. This will clearly depend on the parameter and application.

Answer 3

JMS is the J2EE way of doing this. You can start your own threads if the container lets you, but that does violate the J2EE spec (you may or may not care about this).

If you don't care about J2EE generic compliance (if you would in fact resort to threads rather than deal with JMS), the Oracle container will for sure have proprietary ways of doing this (such as the OracleAS Job Scheduler).

Answer 4

Using the JMS is the right way to do it, but it's heavier weight.

The advantage you get is that if you need multiple servers, one server or whatever, once the servers are configured, your "Threading" can now be distributed to multiple machines.

It also means you don't want to send a message for a truly trivial amount of work or with a massive amount of data. Choose your interface points well.

Answer 5

see here for some more info: stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged

I've been creating threads in a container (Tomcat, JBoss) with no problem, but they were really simple queues, and I don't rely on clustering.

However, EJB 3.1 will introduce asynchronous invocation that you may find useful: http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=700869&l=EJB3-1Maturity&asrc=EM_NLN_6665442&uid=2882457

Answer 6

JEE doesn't really forbid you to create your own threads, it's the EJB spec that says "unmanaged threads" arn't allowed. The reason is that these threads are unknown to the application server and therefore the container cannot manage things like security and transactions on these threads.

Nevertheless there are lots of frameworks out there that do create their own threads. For example Quartz, Axis and Spring. Changes are your already using one of these, so it's not that bad to create your own threads as long as you're aware of the consequences. That said I agree with the others that the use of JMS or JCA is preferred over manual thread creation.

By the way, OC4J allows you to create your own threads. However it doesn't allow JNDI lookups from these unmanaged threads. You can disable this restriction by specifying the -userThreads argument.