Sahil
Mon Aug 21 15:14:14 CDT 2006
A database doesn't care if you are running multiple threads in your app or
not. Multiple threads versus multiple processes - same difference as far as
the DB is concerned. (Assuming you aren't sharing the connection).
And transactions are supposed to lock each other - that is what they are
designed for. They lock and thus keep your data clean. Your only other
option is to lower the locking by tweaking the isolation behavior of the
transaction, and work with unclean data. Can't have it both ways :-/
Now there are certain database design patterns you can use to lower the
probability of the lock, yet keeping the data clean - you can use that as a
midway approach.
These are both topics that you can write chapters about, so I can't cover
each detail in it's entirety in a reply to a NG. I'd recommend picking up a
book that gives a good treatise on transactions. I've attempted to do so in
my book.
- Sahil Malik [MVP]
http://blah.winsmarts.com
"Smokey Grindle" <nospam@dontspamme.com> wrote in message
news:OoKrmuVxGHA.2120@TK2MSFTNGP03.phx.gbl...
>I have a program that runs on multiple threads working with database sproc
>calls... these need to be all ran in transactions.... how can I get
>something similar to parallel transactions or at least to the point where
>they dont cause each other to crash? They all work with the same database
>connection...thanks!
>