locked
Multi Threaded App WIth SQL RRS feed

  • Question

  •  

    I have a data collection application that spawns a thread for each data collection source to parse and submit the data to an SQL 2005 database.  Everything works fine until I connect with a second client.  Then, none of the threads can submit  data to SQL. 

     

    At the moment, each thread opens its own data connection and submits data to its own table in the database.  I'm sure I need to move the SQL data connection out of the threaded process but I'm not sure what the best way of doing this is.  Any leads on where to look for more informaion on this would be a great help.

     

    Thanks..

    • Moved by jack 321 Monday, June 2, 2008 7:24 AM off topic
    Wednesday, May 28, 2008 4:26 PM

Answers

  •  EVC wrote:

     

    I have a data collection application that spawns a thread for each data collection source to parse and submit the data to an SQL 2005 database.  Everything works fine until I connect with a second client.  Then, none of the threads can submit  data to SQL. 

     

    At the moment, each thread opens its own data connection and submits data to its own table in the database.  I'm sure I need to move the SQL data connection out of the threaded process but I'm not sure what the best way of doing this is.  Any leads on where to look for more informaion on this would be a great help.

     

    Thanks..

     

    Can you lock each thread and check if the transaction is completed, then unlock the thread that just completed the operation and proceed with the next one?

     

    At the same time, it should not be happening. Come to think of it. Why do we have two or more clients? Are you using user instances? Could it be the case?

     

    Sql Server must have an in-built mechanism to handle simultaneous data downloading into two separate tables. Something must be wrong with your code set-up, could it be?

    • Proposed as answer by Linda Liu Friday, May 30, 2008 9:07 AM
    • Marked as answer by EVC Thursday, October 2, 2008 3:03 PM
    Wednesday, May 28, 2008 6:38 PM

All replies

  •  EVC wrote:

     

    I have a data collection application that spawns a thread for each data collection source to parse and submit the data to an SQL 2005 database.  Everything works fine until I connect with a second client.  Then, none of the threads can submit  data to SQL. 

     

    At the moment, each thread opens its own data connection and submits data to its own table in the database.  I'm sure I need to move the SQL data connection out of the threaded process but I'm not sure what the best way of doing this is.  Any leads on where to look for more informaion on this would be a great help.

     

    Thanks..

     

    Can you lock each thread and check if the transaction is completed, then unlock the thread that just completed the operation and proceed with the next one?

     

    At the same time, it should not be happening. Come to think of it. Why do we have two or more clients? Are you using user instances? Could it be the case?

     

    Sql Server must have an in-built mechanism to handle simultaneous data downloading into two separate tables. Something must be wrong with your code set-up, could it be?

    • Proposed as answer by Linda Liu Friday, May 30, 2008 9:07 AM
    • Marked as answer by EVC Thursday, October 2, 2008 3:03 PM
    Wednesday, May 28, 2008 6:38 PM
  •  

    Each client is a manufacturing machine dumping data via the network to a parser that then submits it to a sql database.  Using a single client would make it difficult to capture all the data due to the rate in which it is delivered.
    Wednesday, May 28, 2008 9:39 PM
  •  EVC wrote:

     

    Each client is a manufacturing machine dumping data via the network to a parser that then submits it to a sql database.  Using a single client would make it difficult to capture all the data due to the rate in which it is delivered.

     

    Maybe your parser is the bottleneck?

     

    I am not advocating a sinlge client. I am saying what you are describing is not supposed to happen.

    Wednesday, May 28, 2008 10:26 PM
  • You were right, not only shouldn't it be happening...it wasn't  LOL

    I found the problem and it had nothing to do with the multi-threaded aspect of the application.  It was a logic error in the code.  As soon as I fixed it, all the SQL stuff started working just fine.

     

    Thanks for your help.  You gave me enough to actually start looking in another direction.

     

    Thursday, May 29, 2008 5:29 AM
  • Glad. A happy ending. Could have been more tragic:) Just kidding.
    AlexB
    Saturday, May 31, 2008 12:37 AM