Own thread in a Java EE server - State of the art

Question

I know this is considered bad practice, and forbidden in some case (ejb).

So, there are three distinct questions:

1. what is the state of the art, specifically with JSR 236 that should address the question. Is that already included in some application server ?

2. The forbidden rule talks about a Java EE container. What about Tomcat ? That it is not a fully featured Java EE container.

3. I already searched the web and found many resources talking about the matter, but they are mainly blogs and posts about experience, and all of them are quite old. Do you have some links, an official one from Sun/Oracle would be better, that explains in great detail what is going on with threads and Java EE. Or at least, if it is not forbidden by SO policy, a good book.

[UPDATE]

For 'own thread' I mean to use either the java concurrency or the classic runnable interface with start, wait etc.

Answer 1

what is the state of the art, specifically with JSR 236 that should address the question. Is that already included in some application server?

JSR 236 (Concurrency utils for Java EE) has eventually became part of Java EE 7. Java EE 7 is currently implemented by GlassFish 4, and it's expected that Wildfly 8 (formerly JBoss AS/EAP) will implement it early next year.

A current disadvantage of JSR 236 is that you cannot define your own thread pool; you have to do with the one provided by the application server which (IMHO) seriously affects the usability of the specification. You may be able to work around this limitation using proprietary methods, e.g. perhaps by interacting with a graphical UI or by modifying some file in the installation directory of your application (which you are typically not allowed to do in bigger companies).

See this for some additional resources about JSR 236.

Answer 2

I can't think of too many occasions when this is the right thing to do.

One of the biggest problems when creating your own threads is that, depending on how you create them, they don't have access to all the features you're using a container for in the first place.

I recommend you try to use some sort of listener and then call an @Asynchronous method on your favorite bean. Just remember that in order for @Asynchronous to work, it has to be called through a proxy otherwise the container doesn't know anything about the call and it ends up being a normal method call in the same thread.

class MyListener {
    private MyBean proxy;

    MyListener(MyBean proxy) {
        this.proxy = proxy;
    }

    void handler(MyEvent event) {
        proxy.handler(event);
    }
}

@ApplicationScoped
public class MyBean {

    private MyBean proxy;

    @PostConstruct
    private void init() {
        // Use JNDI or BeanManager to get a proxy to this bean
        proxy = ??
    }

    @Asynchronous
    void handler(MyEvent event) {
    }
}

Now, even if the listener you are using doesn't abide by the container thread rules, you can still use the container features in your handler. I use this to take events off of Maps, Queues and Topics in Hazelcast and it works great.

If you are still bent on doing threads, here is an article that explains a pretty clean way of doing it (http://www.adam-bien.com/roller/abien/entry/conveniently_transactionally_and_legally_starting).