hibernate一直的疑问

先汗一个啊!
用户A 在A机 执行步骤
1.首先执行一个select tableA 获得持久化的tableA
2.用tableA的数据做一个耗时间的操作,得到结果C!
3.显示tableA的数据到表现层(此时应该还是用步骤1中持久化的tablea吧?)

如果用户B在B机.在用户A在A机做步骤2的同时!
删除了很多tableA的数据!

那用户A在A机的第三个步骤,就会显示出很多已经被用户B在B机已经删除的数据



另外想问一下如果没有集群的话:

用户A 在A机 执行步骤
1.首先执行一个select tableA 获得持久化的tableA
2.用tableA的数据做一个耗时间的操作,得到结果C!
3.显示tableA的数据到表现层(此时应该还是用步骤1中持久化的tablea吧?)


如果用户B也在A机,在用户A在做步骤2的同时!
删除了很多tableA的数据!并持久化了tableA

那用户A在A机的第三个步骤,使用的是自己在步骤1持久化的tableA.
还是使用的用户B持久化的tableA?

用户A 在A机 执行步骤
1.首先执行一个select tableA 获得持久化的tableA
2.用tableA的数据做一个耗时间的操作,得到结果C!
3.显示tableA的数据到表现层(此时应该还是用步骤1中持久化的tablea吧?)

如果用户B在B机.在用户A在A机做步骤2的同时!
删除了很多tableA的数据!

那用户A在A机的第三个步骤,就会显示出很多已经被用户B在B机已经删除的数据



另外想问一下如果没有集群的话:

用户A 在A机 执行步骤
1.首先执行一个select tableA 获得持久化的tableA
2.用tableA的数据做一个耗时间的操作,得到结果C!
3.显示tableA的数据到表现层(此时应该还是用步骤1中持久化的tablea吧?)


如果用户B也在A机,在用户A在做步骤2的同时!
删除了很多tableA的数据!并持久化了tableA

那用户A在A机的第三个步骤,使用的是自己在步骤1持久化的tableA.
还是使用的用户B持久化的tableA?

使用oschahe等支持集群的缓存机制来解决.
如果应用比较大,机器比较多,之间又不需要同步的话.
需要专门做一个集中式缓存来解决这些问题

楼主应该买本hibernate实战看看。
这些问题不应该是由论坛给你解答的

照这么说，就算解决了并发问题，那么A的操作结束后数据返回客户端过程中B去删除了A表数据，A用户一样会看到很多已经被B删除的数据。
首先，这个问题无发避免，
其次，这个问题无关痛痒：只要A看到的数据是正确、一致的就可以，在客户端看到的任何数据当然都可能是过期的，只要保证用户不会因为使用过期数据造成别的错误
前面我也说了，离线乐观锁可以解决这个“用户不会因为使用过期数据造成别的错误”的问题
例如把version作为session变量或表单hidden字段

如果不用二级缓存，集不集群 行为都一样

楼主的问题应该问的是一个基本问题：就是数据修改后，缓存中会不会是旧数据的问题。跟锁，集群没有什么关系。

楼主自己也说了，只是看过Hibernate文章，实践过1-2次而已。其实楼主应该怀着这个疑问，写个例子测试一下就知道了，例子不难写。

其实这是个很简单的问题，你想想 Hibernate 会不会这么弱，Cache打开时，无法发现 table A 被第二个用户做了更新操作？
当然不会，你可以用一个简单的逻辑考虑：Hibernate既然很强大，Gavin King他老人家不可能解决不了这个小 case。


至于原理， table A 被第 用户 B 修改后(其实跟B机器没有关系，在A机修改也一样，楼主说的 A,B机应该是浏览器吧？ )， Cache 会更新 table A在 UpdateTimestampCache 中的时间戳， 并且，被修改的记录，例如 id = 78，会自动在 二级缓存区域中 修改它； 下次 A 用户再查询  table A 时， 仍从缓存中读取， 由于Cache中的 id=78记录已被修改，所以查询到的数据就是最新的了。 至于 删除， 新增类似的原理。


还是那句话： 实践一下，不要老想！ 楼主应该怀着这个疑问，写个例子测试一下就知道了，例子不难写。

to 楼上的：你说的是二级缓存，不在本讨论范围内

一般还是使用乐观锁的!这样好些!

哪你每次updata完session.close()就解决问题了

right，请楼主搜索“离线乐观锁”或“离线悲观锁”再来讨论，这和什么一级缓存二级缓存没有直接关系。

更多的是从业务上来考虑，尤其是“离线悲观锁”。