I'm writing an app which uses MDBs, EJBs and needs ThreadLocal to pass and log a variable across multiple EJBs and Helper classes until the transaction is complete.
The flow is
Starting with MDB onMessage()
-> some business delegate EJBs
-> some helpers
Question:
This app runs within Weblogic and Weblogic re-uses Threads from within it's ThreadPool. So is there a possibility of data corruption across threads? Is the solution to use ThreadLocal.remove() safe enough?
Is there an alternative to ThreadLocal other than passing around the Object as a parameter to all methods?
WebLogic does not reset user set ThreadLocal variables when the thread is returned back to the pool - the user is responsible for managing them. When such threads are reused, its likely they will interfere. You may run into memory leaks since the thread local reference isn't cleaned up. You can safely reset your thread locals prior to returning the thread back to the container. The ThreadLocal.remove() call should clean it up (ensure that its done in a finally block)
Note that if any async or rmi calls are involved, your thread locals will not propagate. You may want to consider the WebLogic WorkArea feature which allows context propagation across threads, clients & servers. More details can be found at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13706/context.htm#i1058690
You can't reliably use a ThreadLocal in the EJB tier. Even if your code seems to 'work' now, what happens if someone deploys one of your beans remotely? From EJB Restrictions:
Why is thread creation and management disallowed?
The EJB specification assigns to the EJB container the responsibility
for managing threads. Allowing enterprise bean instances to create and
manage threads would interfere with the container's ability to control
its components' lifecycle. Thread management is not a business
function, it is an implementation detail, and is typically complicated
and platform-specific. Letting the container manage threads relieves
the enterprise bean developer of dealing with threading issues.
Multithreaded applications are still possible, but control of
multithreading is located in the container, not in the enterprise
bean.
If you need to share state, you should pass it in to the EJB method as a parameter. Is there a reason this approach won't work for you? Another option would be to temporarily dump it into a transaction enlisted database or cache.
#JoseK: though I have not tried what you described in your issue, but here are my thoughts:-
Both MDB and Session beans are thread-safe. It means let us say if there is pool of 10 beans, only 10 requests will be handled simultaneously. Other requests would be queued for their turn. So one running thread local data should not interfere with other thread.
If you confident to use always local EJBs in future also, then I don't really see any issue in using thread local data. Because you are not really creating threads.
Though weblogic provides thread from thread-pool but that thread is given dedicately to each request flow, I don't think its local data should become corrupted ever.
As I said I have not tried myself, what I would try is:-
In MDB layer(your first layer), do Thread.getCurrentThread.setName(name)
and in subsequent layers print thread names like Thread.getCurrentThread.getName)
Perform multiple runs with different size of ejb pool, thread pool. Give a different thread name to each request flow. Try running multiple requests same time. And see if you ever get thread name mixed.
5.Having said above, to keep things simpler and furture remote EJB support, I would also pass CallingContext Interface to each layer.
Related
I'm currently working on an app which is heavily connected to maps. To display a map, we are generating a bunch of tiles in many threads, store them and get them if a user wants to see a certain part of the map.
The problem is, I'm naming threads that generate tiles a certain way, but then, when I want to get tiles to show a map, my servlet container's taking random threads from the pool, so the thread named for generating a tile ends up getting it from the storage. Of course, I could just rename the thread after generating a tile back, but I wonder if there is an alternative.
I wonder if I somehow can configure my servlet container for it to maybe kill threads after some time being idle or to create a new thread where I want to or to allocate several threads to work with this part of the code?
All I could find in terms of configuring servlet container is setting its min and max thread pool size, which I think won't help me.
The container is 100% in control over it's threading.
If you are attempting to manipulate the threading of the container then you are fighting a losing battle.
It is not possible to safely kill or stop threads on a running container, as this is incredibly unsafe, and will lead to many memory issues (leaks) and unclosed resources. The Thread.stop() method has been deprecated since Java 1.2.
Now that we have the negatives out of the way ...
Jetty is a 100% Async Java Web Server.
The classic assumption that 1 request uses 1 thread is wrong. (if you want this kind of behavior, then you should use Jetty 6 or older. Jetty versions older than 9.2 are now all EOL / End of Life)
When you use a Servlet call that is traditionally a blocking call, the Jetty server has to fake that blocking call to satisfy the API contract.
Even if using old school / traditional blocking Servlet APIs you'll still experience many situations where that 1 request has been handled by multiple threads over the lifetime of that 1 request.
If you want to work with the Servlet API and it's container then the first thing you should do is start to use both the Servlet Async Processing APIs and Servlet Async I/O APIs combined. Make sure you read about the gotchas on both APIs!
Async Processing will allow you to handle more processing of requests on the server side, not use the container threads that heavily, allow more control over how the threading behaves, will grant you better control over request timeouts, and even get notified of request/response error cases that you will always deal with on a web server.
Async I/O will allow you to only use a thread if there is content from the request/connection to read or if the connection allows a write. That connection will not consume a thread unless I/O is possible. This means more connections/requests per server, and ill behaving clients (slow, dead, problematic, etc) will not impact the behavior of your other clients by consuming threads that are not doing anything productive for you.
If you don't want to work with the Servlet API and do things your own way, then you'll have to manage your own Executor / ThreadGroup / ThreadPool that the server is unaware of. But that still means you'll need to use the Servlet Async Processing APIs to allow the 2 to coexist in harmony (you'll need to use the AsyncContext to inform the container that you are now taking control over the processing of the request, and then later inform it via the AsyncContext that you are done and the request is complete).
The biggest gotcha with this approach is that you cannot safely write to the HttpServletResponse from a thread that the container wasn't in control over.
Meaning the container dispatched on a thread to your application, that thread is the only one that can safely use the HttpServletResponse to write the response. You can have a different thread do the processing, a different thread provide the data to the HttpServletResponse, even a different thread that pumps the dispatch thread with content. But that thread you were dispatched to needs to be used to write.
This is the mixed threading behavior gotcha in the servlet spec. (you are in servlet async mode, on a different thread to process, but not using async mode to read/write.) It's a terribly complex, and ill defined, behavior in the servlet spec that leads to many issues, and I advise you to not chase this path.
This gotcha goes away if you also use the Servlet Async I/O APIs, but at that point the difference in the two above choices is negligible.
I am working on a web service and creating thread local instances and only want to remove them during app shutdown (once a threadlocal object is created for thread I want use that object during different service calls on that thread). As threads are created and owned by tomcat , is there any way to remove those threadlocals during application shutdown ??
Tomcat 6 has memory leak detection in place, and Tomcat 7 has actual removal logic - it will automatically remove all thread local objects for you: http://wiki.apache.org/tomcat/MemoryLeakProtection
Ideally you should remove all objects from thread local after request is completed, since the same thread is going to be put back to thread pool and used to serve other requests - in this case thread local values may interfere with subsequent request logic, and cause all kind of security issues.
But if you're specifically looking to keep values in thread local for the whole duration of Tomcat webapp lifetime - Tomcat 7 will take care of cleaning it up for you on webapp shutdown, think of it as garbage collection.
(1) Okay I am pretty confused about the threading model of JAX-WS Java web services. I read they are not thread-safe. How are they supposed to serve multiple parallel requests then? Given that its always known (mostly) they are going to get called from multiple clients at the same time.
(2) And does the app server create a new instance of web service for each request (like it maintains a pool of stateless session beans, assigns one out for a request and once the request completes, it is returned to the pool). can you configure that pool size in app server console (GlassFish or JBoss or WebSphere).
(3) And I also found out about #Threadsope annotation here which creates new thread per request..
http://jax-ws-commons.java.net/thread-scope/
Is that a good option? I am sure people are solving the thread-safety and parallel requests issues in some other standard way - please advise.
An application server contains a pool of beans.
When working with stateless session bean, it is not guaranteed you will get the same instance across working with the session.
However, since as I mentioned, the beans are managed by a pool, holding a state in them, is a bad idea.
I don't think that EJB beans have anything to do with what your need, though.
Pay attention that in the example you provided, Both DataService and the connection are created per request. This is a bit expensive.
I would consider using the ThreadLocal API only for the connection, and have it obtained from a connection pool.
You can implement these on your own, by reading about ThreadLocal and by reading about DB connection pools.
To conclude - I don't think EJBs are relevant here.
Don't hold both your service class and the fields at the thread local, but only the necessary fields you will allocate per request. (in the example you showed - it's the connection)
Is it recommended to use ThreadLocal to store a Thread Context?
I am building a backend server application where there are typical services that I need to run.
Note: We are not building this over a SOA architecture.
Before the start of each service I need to give it a state which has some Service Contex which is variable map to work up on. This variable map is shared when services are running parallelly.
Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.
Question: Is it a good approach to keep the thread context inside thread local and then building api's over service context to access parameters over these variables.
This would help me to hide the complex behavior and it wouldn't open up my internal things.
Thanks,
Aditya
It looks like your server application framework ought to provide you with the means to implement this functionality in a simpler way - unless you are implementing your own framework.
Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.
An EJB container provides this kind of functionality. EJBs also provides a session context and the means to ensure that the context can be restored if execution is transferred between threads (by passivation + activation).
You can use ThreadLocal quite freely but you must define your thread model cleanly (see if you have any control on the thread creation)... also keep in mind that assuring the state stored in the ThreadLocal might not what you expect, if you are relying on any clean-up code.
Also: do use (cant stress more) WeakReference for anything that your code is not directly responsible.
I need to implement a pool of Sessions that are returned by an external system,
so that I can reuse them quickly as soon as one is needed (creating a Session takes a while).
I've worked with datasource to create a pool of database connections (DBCP from Apache), and it was
an implemented solution.
What do we use in a general case to pool arbitrary objects, and are there implemented solutions, ie objects, not interfaces, to deal with the task painfully?
Second question would be, how do we test whether the Session is alive ? Is there a specific method that we override in the Object pool, that queries the Session's own methods?
The third, VERY IMPORTANT question, would be, should that object pooling object be static? A bundle of objects I extract from the system must be shared among different web applications. So, say, we extract 5 Sessions. App A queries the POOL and gets the first available Session. Now there are 4 Sessions left. Another App B starts and queries THE SAME POOL. etc The pool is shared. Among different instances of the same web app, running on the same machine.
For a generic pool of objects,
you have an Apache Commons
project for that.
For testing
that a session is alive, there are
different ways, but many of them are
unreliable. And the reliable one
(doing a query on dual) is slow.
You can have a look at c3p0,
which has that feature built-in.
As long as your many webapps are in the same WAR file, I think you'd be OK to use this static pool object. Although, personally, I prefer singletons over static objects that have anything more than utility methods and constants.
In general, I'm a big fan of Hibernate... have you considered using it for your application? You can still make plain SQL queries through it, and it handles your pooling and caching for you.
If you are using a J2EE application server then consider building a component implementing the Java Connector Architecture (JCA). Each instance of the component accesses a single Session and you configure the container to create at most five (from your example) instances. The container manages the pool and the component's lifecycle. Additionally, all applications deployed on that application server share the component's pool.
If I remember correctly (its been a while) there is also a way to signal the container that an instance died. In this scenario, the container removes the dead instance and instantiates a new one.
Some non-J2EE application servers have support for JCA components so check into it even if you are not using a traditional J2EE container.