File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Database access, potential threading problem? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Database access, potential threading problem?" Watch "Database access, potential threading problem?" New topic
Author

Database access, potential threading problem?

Alex Kravets
Ranch Hand

Joined: Jan 24, 2001
Posts: 476
I have a class that I use to connect to database, select, insert, delete and modify records, basic stuff. Here is part of code:

Now, in my JSP I call this class as:


This works fine, but is there a chance for threading problem where Vector of user's calling DBDriver.doSelect() will be overwritten by other user's doing the same opearation? Should call to DBDriver.doSelect() be synchronized?

thanks,
Alex


All right brain, you don't like me and I don't like you, but let's just do this one thing so I can get back to killing you with beer.<br /> <br />- Homer Simpson
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
As you have coded it, it should be threadsafe.

Here are a few other things to note:
  • You can safely look up the DataSource just once if you don't actually change the "clientName/conName" during the life of the program. The Connection is the one you need to acquire from the DataSource each time, but the DataSource itself is threadsafe and cachable.
  • The finally block is executed if the try block is entered whether or not the try block throws an exception and regardless of what happens in any of the catch blocks. Thus, you should remove the calls to closeConnection() from the catch blocks.
  • Vector itself is synchronized which is rarely needed. Unless you're stuck using JDK 1.0 or 1.1 or old code with Vector throughout, I recommend switching to the unsynchronized replacement: ArrayList. Check out the other collection classes as well like HashMap (instead of Hashtable), Set, etc.


  • [ February 02, 2005: Message edited by: David Harkness ]
    Alex Kravets
    Ranch Hand

    Joined: Jan 24, 2001
    Posts: 476

    Vector itself is synchronized which is rarely needed. Unless you're stuck using JDK 1.0 or 1.1 or old code with Vector throughout, I recommend switching to the unsynchronized replacement: ArrayList. Check out the other collection classes as well like HashMap (instead of Hashtable), Set, etc


    But if I switch to unsynchronized collection, won't my code become thread unsafe?
    [ February 03, 2005: Message edited by: Alex Kravets ]
    David Harkness
    Ranch Hand

    Joined: Aug 07, 2003
    Posts: 1646
    Originally posted by Alex Kravets:
    But if I switch to unsynchronized collection, won't my code become thread unsafe?
    Only if you have multiple threads accessing the same Vector object. Note that each call to your method returns a different Vector object: "data = new Vector(50,5);".

    The only way this could happen is if after the call to retrieve data -- "Vector data = DBDriver.doSelect(...)" above -- you handed the "data" Vector to multiple Threads for processing. If instead each Thread processes its own Vector, they cannot interfere with each other.

    You might want to go through Sun's multi-threading tutorial to make sure you understand exactly what thread-safe and synchronization means for objects versus classes.

    Think of it this way. If you have a car and I have a different car, we can both drive our cars at the same time. The "idea of a car" is not synchronized. If, however, we share a single car, then only one of us can drive it at the same time. Thus, "driving a car" is a synchronized operation on each car individually.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Database access, potential threading problem?