I have a class, ProcessorClass. It has two methods Start() and Stop(). When you hit start, it internally creates a bunch of threads that do some processing and, if they find something relevant, fire an event.
My form frmMain (this is a windows forms app .net 3.5) has an instance of this class and is catching these events. Each time an event is caught, something gets inserted into the database. Am I right in concluding that this strategy will ensure synchronous inserts? I can’t have multiple threads trying to do data operations as that would cause me to lose data.
No, these won’t be synchronous inserts, especially on multicore machines. Rather than going back to single-threading, or locking on some object in memory, I’d suggest putting concurrency handling in your database updates. You can do that without locks in the database by using a WHERE clause to check old values on the same statement that does the update. If the result has zero rows inserted, then the concurrency check saved you from data corruption.
However, if you don’t have a retry mechanism that works for your business rules, you’ll need to add concurrency specifications to your database transactions. (i.e., open a transaction, attach it to your command, and set the transaction concurrency level to the level of safety that you need).