Why Is Spawning Threads in Java Ee Container Discouraged

Why is spawning threads in Java EE container discouraged?

It is discouraged because all resources within the environment are meant to be managed, and potentially monitored, by the server. Also, much of the context in which a thread is being used is typically attached to the thread of execution itself. If you simply start your own thread (which I believe some servers will not even allow), it cannot access other resources. What this means, is that you cannot get an InitialContext and do JNDI lookups to access other system resources such as JMS Connection Factories and Datasources.

There are ways to do this "correctly", but it is dependent on the platform being used.

The commonj WorkManager is common for WebSphere and WebLogic as well as others

More info here

And here

Also somewhat duplicates this one from this morning

UPDATE: Please note that this question and answer relate to the state of Java EE in 2009, things have improved since then!

Is it discouraged to use Java 8 parallel streams inside a Java EE container?

EDIT See alternate answer from andrepnh. The below may have been the plan, but it doesn't appear to have played out that way in practice.

---

The way I read it from the lambda-dev mailing list discussion mentioned in the comments: it's not discouraged the way spawning threads is - but won't do anything much for you in a Java EE context.

From the linked discussion:

the Java EE concurrency folks had been already talked through
this, and the current outcome is that FJP will gracefully degrade to
single-threaded (even caller-context) execution when running from within
the EE container

So you're able to safely use parallel streams in a procedure or library that runs in both contexts. When it's run in a SE environment, it will make with the magical parallel shenanigans - but when it's run in an EE environment it will gracefully degrade to serial execution.

Note: the phrase quoted above is future tense - does anyone have a citation for some definitive documentation?

Can an embedded XMPP server in a Java EE container be harmful because of threads?

some things are forbidden but it is less and less strict and tomee (and most EE servers) doesn't impose it otherwise you can pretty much do nothing.

Only surprise you can get is to expect to be managed (security, CDI, ...) and since that's not container threads then you are not. If you accept this rule of the game then no issues.

PS: don't forget to shutdown correctly your threads

Java EE specification and multi threading

This question pops up once in a while.

As per the spec it's not authorized. The best page to look at is this one: Q/A: J2EE Restrictions

That said, there are ways to spawn threads, especiall in Weblogic with the WorkManager.

See these questions:

• How can an EJB parallelize a long, CPU intensive process?
• Why spawning threads in J2EE container is discouraged?
• J2EE programmers do not write to files

The fact that the first one targets EJB shouldn't matter that much, and the last one about access to file system is about general restrictions.

Hope it helps.

What is the correct way to create threads in an enterprise java application

The correct way to do this is by using the Concurrency Utils API, which is part of the Java EE7 release. Creating threads this way ensures that the thread has access to all the other enterprise services. Using the Concurrency Utils ensures that your thread is created and managed by the container.

Please see here and here for examples

Why use @Asynchronous in EJB when we can use ExecutorService?

Basically, the answer can be found in the EJB 3.1 specification:

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.



These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.

I guess the explanation speaks for itself. Java EE is typically implemented in a container on an application server, and the specification has been designed to give the container the best conditions to effeciently do its job.

Another reason I can think of, and I guess one of the reasons the Java EE specification exists at all, is that it allows for reusability. There is no need to reinvent the wheel, so to speak.

Writing on a separate thread for a web app

Creating your own threads in a J2EE application is strongly discouraged and is outside the J2EE specification. I don't think you'll find a J2EE library to do what you want.

One of the main benefits of J2EE is that the server manages all your threads (and other resources) for you. If you start creating your own threads, the server doesn't know about them and can't look after them, so you're opening yourself up for potential resource leak problems amongst other headaches. To coin a phrase, you don't get a dog and bark yourself.

You'd be better off trying to create a solution that uses JMS. JMS is all about processing queues of messages so should be a good match to your requirements. Here's an article that talks about this a bit.

---

Related Topics