locked
Synchronization across multiple processes RRS feed

  • Question

  • Hi all -

    I have written a Console app that uses multiple threads.  I have ensured synchronization among the threads in the app by using the lock statement.  (What is being locked is a call to a select SQL statement).  However, I need this program to be running on several machines simultaneously.  Will the lock() statement ensure synchronization between threads in my app running on Machine A and the threads in my app running on Machine B?

    Thanks in advance!
    Monday, July 6, 2009 1:07 PM

Answers

  • Stop trying to move the problem around and having to solve it at several locations that only makes it harder to solve, solve it once at the place it should be solved : in the database. Either make it a autonumber anway and retrieve the record ID after you insert it using the @@IDENTITY variable so you can use it in other queries or if you really want to desperately want to keep doing what you are doing now emulate oracles sequences with something like this .
    Monday, July 6, 2009 2:07 PM
  • Archimedes0212 you're doing fine.  Ray is correct that you should move some of this to the database.  If you are using an auto-incrementing table but need to know the value of the UID of that table's row then have you looked at using a stored procedure?  If written properly you can transform your SQL statement from a, um, "void"-type "function" to an "int"-type "function."  It will return the actual value of the row.  A good example can be found within the book ADO.NET Cookbook.  This book has served me well in my ventures down database lane.  Quite a number of useful items.
    Monday, July 6, 2009 3:08 PM

All replies

  • Thread synchronisation is to ensure two threads don't read/write at the same location in memory cause that would cause undeterministic results, the fact that you abused this to manage an sql statement is the least to say unfortunate there's no way to pull this across serveral machine boundaries since its never intended to solve that problem.  You are better off fixing whatever problem the sql statement is causing you then fighting the sympthons.

    Monday, July 6, 2009 1:23 PM
  • Okay, so I went about it the wrong way.  Does anyone have a suggestion for a 'proper' way to do what I'm aiming to do??

    Thanks.
    Monday, July 6, 2009 1:30 PM
  • I Have no clue what the issue is with your sql statement, SQL Server is fine with tons and tons of people hammering it at the same time why do you need to manage this specific query?
    Monday, July 6, 2009 1:39 PM
  • It's actually a couple queries.  I first execute a select query to get the last value inserted.  My C# app uses this returned value to produce a new one which is then inserted into the table.  I am not using an auto incrementing value because I need the value for other methods in my C# and other tables.  So really, I need synchronization because there are multiple queries being executed and no two threads can get the same value from the initial select query
    Monday, July 6, 2009 1:48 PM
  • Stop trying to move the problem around and having to solve it at several locations that only makes it harder to solve, solve it once at the place it should be solved : in the database. Either make it a autonumber anway and retrieve the record ID after you insert it using the @@IDENTITY variable so you can use it in other queries or if you really want to desperately want to keep doing what you are doing now emulate oracles sequences with something like this .
    Monday, July 6, 2009 2:07 PM
  • 1) I'm trying to solve it in the database now.  I asked for help and am taking advice that I am receiving.

    2) I'm looking into the @@IDENTITY - If you couldn't tell, I'm new to this whole SQL Server thing.

    3) I'm sorry that I don't catch on quite as fast as you want me to, but don't get testy and impatient.  If I'm bothering you that much, stop replying to me.  I'm doing the best that I can
    Monday, July 6, 2009 2:22 PM
  • No need to feel attacked, i'm just pushing you to have you drop your original idea (which was bad) on how to solve the issue and move towards a proper solution. Sometimes people need a little push, sure i might look like a mean ____ but you're building a better app now because of it.   :)

    Monday, July 6, 2009 2:48 PM
  • Archimedes0212 you're doing fine.  Ray is correct that you should move some of this to the database.  If you are using an auto-incrementing table but need to know the value of the UID of that table's row then have you looked at using a stored procedure?  If written properly you can transform your SQL statement from a, um, "void"-type "function" to an "int"-type "function."  It will return the actual value of the row.  A good example can be found within the book ADO.NET Cookbook.  This book has served me well in my ventures down database lane.  Quite a number of useful items.
    Monday, July 6, 2009 3:08 PM
  • Ray M_ and wheaties:

    Thanks for the help.  Yes I am using a stored procedure from which I am getting the data that I need.  It's a slow process, but slowly but surely it's working.
    Monday, July 6, 2009 3:22 PM
  • While the database solution is much more elegant, I've also found another way to go about tackling this problem.

    Mutexes in C# will do the trick, if you call mutex.WaitOne() before the SQL queries you are trying to synchronize and mutex.release() afterwards.
      Unlike lock(), Mutext works across processes.  Just an fyi for anyone else who stumbles across this thread
    Tuesday, July 7, 2009 6:15 PM
  • Pay attention though depending on your mutex name it might or might not apply to other window sessions (Desktops) running on the same computer and it will definitly not synchonize across multiple machines.
    Tuesday, July 7, 2009 6:37 PM