This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Soft Skills and have John Sonmez on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Multi-threaded, jdbc applications. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Multi-threaded, jdbc applications." Watch "Multi-threaded, jdbc applications." New topic
Author

Multi-threaded, jdbc applications.

Heath Lilley
Ranch Hand

Joined: Jan 09, 2001
Posts: 72
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.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31054
    
162

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Heath,


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

Joined: Jan 09, 2001
Posts: 72
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 agree. Here's the link: http://aspose.com/file-tools
 
subject: Multi-threaded, jdbc applications.