如果你是用到想SQL Server 这种数据库的话,可以不用考虑这个。因为 Sql Server 是自带排他锁的。
如果你第一个人预定完成时操作数据库的时候其他人是不能对同一张表同时进行操作的。比如你第一个人要修改 A 表 中的 a 字段 在同时另外一个人是不能访问 A 表中的 a 字段的。然后你订房完成不是修改当前房间状态?既然房间状态已经修改,那么其余的人操纵那个字段时,字段值已经改变。执行结果返回为 False。
就算是出现线程同步,但只要说订房是修改 Sql Server 数据库中的数据,那就不会出现这种情况。因为 Sql Server 自带排它锁。就是 如果当前字段在被操作,在同时,其他任何用户都是没办法操作当前字段。甚至当前表的。在这点上。Sql Server 自动考虑了这种情况。以上面的来说,如果多个用户同时订房,看起来是同时。但在在系统看来总会有差别,那么,系统会先让最先的用户操作请求的数据,操作成功后才会让下一个用户操作。即、如果第一个用户订房成功后,其他用户再请求的时候,房间已经是预定状态。其他用户返回的结果只能是 False你说的那种线程同步,在 LinQ to Sql 里面存在。但也可以避免。
如果你第一个人预定完成时操作数据库的时候其他人是不能对同一张表同时进行操作的。比如你第一个人要修改 A 表 中的 a 字段
在同时另外一个人是不能访问 A 表中的 a 字段的。然后你订房完成不是修改当前房间状态?既然房间状态已经修改,那么其余的人操纵那个字段时,字段值已经改变。执行结果返回为 False。
就算是出现线程同步,但只要说订房是修改 Sql Server 数据库中的数据,那就不会出现这种情况。因为 Sql Server 自带排它锁。就是 如果当前字段在被操作,在同时,其他任何用户都是没办法操作当前字段。甚至当前表的。在这点上。Sql Server 自动考虑了这种情况。以上面的来说,如果多个用户同时订房,看起来是同时。但在在系统看来总会有差别,那么,系统会先让最先的用户操作请求的数据,操作成功后才会让下一个用户操作。即、如果第一个用户订房成功后,其他用户再请求的时候,房间已经是预定状态。其他用户返回的结果只能是 False你说的那种线程同步,在 LinQ to Sql 里面存在。但也可以避免。