请教一个多线程访问不同数据表的同步问题

Question

我觉得不会出现这样的问题,处理这样的问题要用事务处理;
A表还没有提交,它不能可同步到B表的,所以连接到B表的也不能马上删除;它有先后过程之分,先提交完成,再能删除;

Answer 1

感谢各位的答复！感觉的确应该是事务控制的。最后关于事务，还想再确认下以下的认识是否是正确的：引用前面的问题，请问过程是下面描述的这样吗T1：
1. 开始事务
2. 向表A插入一条关联到GP00001的记录 
3. 提交事务T2: 
1. 开始事务
2. 从表B删除GP00001的记录 
3. 提交事务在开始事务到提交事务之间的操作都是在session的缓存中执行的，
所以可以并发，即T1的1，2两步，和T2的1，2两步是并发的，
而提交事务的第3步，是将Session的数据真正反映到数据库，
为了保证数据完整性，MS SQL Server做了同步控制，即对于同一个
数据库的所有事务提交，都是被串行同步起来的（当然可能做优化，
但对使用者透明）。

Answer 2

想知道就是SQL Server对事务的串行化是在事务提交的时候才发生，还是在事务启动就开始了。比如下面两个并发事务
TransactionA： 
1. 开始事务 
2. 处理table1
3. 处理table2
4. ....
5. 处理tableN 
6. 提交事务 TransactionB: 
1. 开始事务 
2. 处理talbe1
3. 提交事务 假设TransactionA先于TransactionB启动了事务，并率先执行了第2步："处理table1",
那么,下面那个推测是正确的: 
1. TransactionB是否需要等到TransactionA执行完成才能执行第2步,
2. 不用担心TransactionA事务的影响,因为串行化是在事务提交的那一刹那才发生的,
这样TransactionA在执行过程当中,其他的小事务依旧能工作,但最后TransactionA
完成之后会得到一个类似这样的ERROR:  Can't serialize access due to concurrent update,并且
rollback.

Answer 3

想知道就是SQL Server对事务的串行化是在事务提交的时候才发生，还是在事务启动就开始了。
>>>都有可能，这个取决於当前事务的隔离层级，请参考books online中关於事务的隔离层级的说明。

Answer 4

应该是提交事务才一把锁住要提交的talbe吧,否则下面的两个并发事务可能会死锁,是不是?TransactionA： 
1. 开始事务 
2. 处理table1 
3. 处理table2 
6. 提交事务 TransactionB: 
1. 开始事务 
2. 处理table2 
2. 处理talbe1 
3. 提交事务