Right or not? Servlets share the same object.

Hi,
the logic is follows:
Every Servlet will create a database object, which will query the database and return the result either boolean,String or Vector back to those Servlets. The creation of the db object for every Servlet is summarize below:
public class ServletNAME extends HttpServlet
{
...
private sqlcmd cmd;
...
public void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, java.io.IOException
{ ...
if (cmd==null){
cmd = new sqlcmd();
}
.....
For this coding, every servlet will share the same DB object for querying, In the past, I will not check "if (cmd==null)" and just let it create an object per request. But it seems waste resource.
But if every servlet share the same object, will it take risk when many people accessing the Servlets? Since I've no experience to build a multi-user application, so I am afraid of causing error for this arrangement. Pls recommend.

PS: sqlcmd is the database class

With servlets, a single instance is created and all threads are allowed to access that single instance (unless the servlet implements the SingleThreadModel)
Due to this behaviour, these two lines are conceptually the same:

Whether it is declared static or not, only a single copy of the variable will exist.
Since JDBC does not enforce or guarantee any thread safety, this is probably a bad idea since you could get different requests tripping over each other.
You are better moving Connection management out to a Connection Pool and handling each Connection as a local variable in the doGet method.
Dave

David,
Yes, currently I'm using connection pool
A connection object will be created in Servlet, and the servlet will 'send' the connection object for Database class use.
Say, from my example,
public sqlcmd sqlcmd;
cmd = new sqlcmd;
and I've already get create a connection object from connection pool, then I will call the database class to query, for example.
Vector result = cmd.queryTable(connection, ...)
With this method, do you think if the risk of "different requests tripping over each other" will exist? Thanks very much!

Make cmd a local variable so each thread won't trip over each other.

As a general "rule of thumb" you should think very hard before declaring any member variables in a servlet. Always use local variables in the do... method (or methods called from it) if at all possible.
Errors because of this seldom show up when you are testing your code yourself, but can cause high-profile headaches on a live server.

Originally posted by Ken Shamrock:
With this method, do you think if the risk of "different requests tripping over each other" will exist? Thanks very much!

Without looking at it very hard, I'd say it was possible you'll have problems.
The problems you'd have would be intermitant, difficult to track and trace, almost impossible to reproduce, and would just go away if you make the Connection a member of the doXXX method. Not worth the danger.
ie everything Frank said

For declaring a local var for db class. Will it waste too many resource if many people visit the site? Also, will the db object be killed once the job done? otherwise, it will kill the server

Always use local variables in the do... method (or methods called from it) if at all possible.

For me, I cant see any need for do this. If the variable is thread-safed, you needn't do that, If it's not, using local variable can solve nothing. I think maybe i missed something or got into the wrong track totally.
Pls. give your comments
Thanks in advance
James

In general the most resource-intensive part of communicating with a database is opening the connection. The smart thing to do is to use some sort of data source which "pools" database connections so that each connection is opened once then used for many requests.
In your do... method, you just request a conection from the pool. You shouldn't need to care whether it is a fresh new connection or a well-used old one. When you have finished with it, return it to the pool.
Sometimes (typically if you are using database login to validate user names and passwords) you will need to open a different connection for each user. In this case, I recommend that when you open your connection you store it in the Session context, and re-use the same connection for all the requests in that session. This is more tricky, so try to avoid it if you can.

If the variable is thread-safed, you needn't do that, If it's not, using local variable can solve nothing.
This is one of the common misunderstandings about Java. Marking a method or variable "synchronized"
does not make it "thread safe". Making something really thread safe can be a lot of work; you also have to consider the thread-safety of every passed-in parameter, every shared object used during processing and every returned value.
In this case, using a local variable does solve the great majority of problems. Local variables exist in an entirely separate context for each thread. As long as you only use the variable within the context of the creating method (and the methods it calls), and don't pass it to the "outside world" by returning it or placing it somewhere other threads have access to, you should have no threading issues.