Multi-threaded, jdbc applications.
Heath Lilley
Ranch Hand
Posts: 72
posted 12 years ago
Hello all,
As part of porting our applications to a new version of Websphere (5.1.1.3) I read the 1.3 J2EE specification. It described how you are not supposed to create your own threads from within the EJB container. We don't really use EJBs at all since our apps are relativley small and self contained, so we usually are limited to writing code in the web container using Struts and DAOs. I tried to find some information in the Spec. for this topic but I am having problems finding a hard answer. (I could just be missing something.)
So my questions are...
Is creating our own threads in the web container a bad thing?
If not, is creating a database connection in the calling thread and setting it into the runnable object for use a valid way to do this?
Thanks in advance.
As part of porting our applications to a new version of Websphere (5.1.1.3) I read the 1.3 J2EE specification. It described how you are not supposed to create your own threads from within the EJB container. We don't really use EJBs at all since our apps are relativley small and self contained, so we usually are limited to writing code in the web container using Struts and DAOs. I tried to find some information in the Spec. for this topic but I am having problems finding a hard answer. (I could just be missing something.)
So my questions are...
Is creating our own threads in the web container a bad thing?
If not, is creating a database connection in the calling thread and setting it into the runnable object for use a valid way to do this?
Thanks in advance.
posted 12 years ago
Heath,
It isn't forbidden to create a thread from a servlet.
I'm moving this to our J2EE forum because it is more of a question about the spec/design.
It isn't forbidden to create a thread from a servlet.
I'm moving this to our J2EE forum because it is more of a question about the spec/design.
[OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Valentin Tanase
Ranch Hand
Posts: 704
posted 12 years ago
Hi Heath,
Maybe bad is a little bit too much, but I would rather stay away of that. The container does a lot of effort to synchronize the data access. This is not an easy task if you consider that many times an execution thread is associated with a transactional context, etc. So inside of the container things are very complex to manage. If you start your own execution thread, then you�re on your own. You must deal with data access, transactions, etc. Unless you don�t have a very strong reason for doing this, you better stay away.
Another thing that you might consider is that the container also manges the threads in a very optimal manner. WebLogic for example has a message-oriented architecture. It creates something named execution queues that could be configured to pool a specific number of threads. Applications can be associated with this execution queues for parallel processing. If your application starts another thread(s) arbitrarily, then WebLogic has no choice but to take more threads from the queue, while other client request will be blocked. If you kill the thread, then the queue will lose the thread and you�re application performances might degrade considerably. Again think twice in orde to open the Pandora�s box.
Why not to use the connection pooling feature that your container provides?
Regards.
Is creating our own threads in the web container a bad thing?
Maybe bad is a little bit too much, but I would rather stay away of that. The container does a lot of effort to synchronize the data access. This is not an easy task if you consider that many times an execution thread is associated with a transactional context, etc. So inside of the container things are very complex to manage. If you start your own execution thread, then you�re on your own. You must deal with data access, transactions, etc. Unless you don�t have a very strong reason for doing this, you better stay away.
Another thing that you might consider is that the container also manges the threads in a very optimal manner. WebLogic for example has a message-oriented architecture. It creates something named execution queues that could be configured to pool a specific number of threads. Applications can be associated with this execution queues for parallel processing. If your application starts another thread(s) arbitrarily, then WebLogic has no choice but to take more threads from the queue, while other client request will be blocked. If you kill the thread, then the queue will lose the thread and you�re application performances might degrade considerably. Again think twice in orde to open the Pandora�s box.
If not, is creating a database connection in the calling thread and setting it into the runnable object for use a valid way to do this?
Why not to use the connection pooling feature that your container provides?
Regards.
I think, therefore I exist -- Rene Descartes
Heath Lilley
Ranch Hand
Posts: 72
posted 12 years ago
Thank you for your response.
I understand that you should only multithread web applications under extreme situations. We have 2 apps that are multithreaded. Both were done this way to get significant gains in performance by doing database access in parallel. By doing this in one of the apps we were able to reduce a report's load time from 20+ seconds to < 10. Performance is really the only time we ever multithread applications and most of the time the functionality we have to provide is not so complex that it takes that long to execute. These are exceptions to the norm.
We do use the application server's connection pooling functionality, sorry for not being clear, I was referring to setting up the connection in the application server thread and setting it into a runnable object for use rather than allowing the runnable object set up it's own connection. Both situations would use the connection pool to obtain a connection.
I understand that you should only multithread web applications under extreme situations. We have 2 apps that are multithreaded. Both were done this way to get significant gains in performance by doing database access in parallel. By doing this in one of the apps we were able to reduce a report's load time from 20+ seconds to < 10. Performance is really the only time we ever multithread applications and most of the time the functionality we have to provide is not so complex that it takes that long to execute. These are exceptions to the norm.
We do use the application server's connection pooling functionality, sorry for not being clear, I was referring to setting up the connection in the application server thread and setting it into a runnable object for use rather than allowing the runnable object set up it's own connection. Both situations would use the connection pool to obtain a connection.
|