CODEWITHSUNDEEP
javajakarta-eeejb
ptriller
ptriller

Reputation: 153

How to start a background process in Java EE

I want to start a background process in a Java EE (OC4J 10) environment. It seems wrong 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 an 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.

Upvotes: 11

Views: 10070

Answers (7)

ashes999
ashes999

Reputation: 10163

I come from a .NET background, and JMS seems quite heavy-weight to me. Instead, I recommend Quartz, which is a background-scheduling library for Java and JEE apps. (I used Quartz.NET in my ASP.NET MVC app with much success.)

Upvotes: 0

Richard Kettelerij
Richard Kettelerij

Reputation: 2174

Java EE 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.

Upvotes: 1

Yishai
Yishai

Reputation: 91871

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

If you don't care about Java EE 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).

Upvotes: 3

lief79
lief79

Reputation: 582

Java EE 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.

Upvotes: 14

Armadillo
Armadillo

Reputation: 1458

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

Upvotes: 1

Bill K
Bill K

Reputation: 62759

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.

Upvotes: 1

akarnokd
akarnokd

Reputation: 69997

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.

Upvotes: 1

Related Questions