那么用版本控制就能完成避免脏读的java控制，只要对exception进行处理了吧。。
在业务层也应该用这种机制来处理吧？对version进行检查就好了吧。原理一样但是得自己实现，同样在对象池中貌似也有这样的问题吧。。最后就跑到jdon大大们的理念中去了。。
那么用版本控制就能完成避免脏读的java控制，只要对exception进行处理了吧。。
那么用版本控制就能完成避免脏读的java控制，只要对exception进行处理了吧。。
脏读是a事务对数据库进行操作,比如更改数据,还没有提交的时候,b进来读了一次数据,之后a事务回滚,b读的数据就是脏读.消除脏读也很简单,当某个数据行/页拥有排它锁的时候,禁止select操作.
而你说所的乐观锁,是为防止在数据行/页上同时加几个排它锁的情况.我是这样理解的
乐观锁原理就象你说的,我到现在还没明白这东西有什么用.数据库默认不就是禁止对同一数据行/页同时加多个排它锁的么?
我对oracle不熟悉,以前一直用的sybase和mysql.查了下oracle的资料,oracle读的时候并不加共享锁(sybase在读的时候要加共享锁,block排它锁,所以不可以进行写操作),只有写的时候才加排它锁.当数据行有排它锁的时候(维护一个回滚段,里面有锁住的内容),当这时有读操作时,从回滚段里读旧的内容.可能造成数据不一致.并不能说哪一种策略就一定好,无非都是在各种因素下选择一种更加合理的做法.就象数据库范式,时间与空间并不是哪一个一定好,只是取某个平衡点而已.
抱歉我理解有误了。。把脏读当作不可重复读了。。
你说得很对，其实这也是我经常在想的问题，对于事务处理，如果更新频繁应该采取什么样的方式来进行会比较好呢？
不过对你提出的：
什么样的数据适合存放到缓存中？
1 很少被修改的数据
2 不是很重要的数据，允许出现偶尔并发的数据
3 不会被并发访问的数据
4 参考数据
不适合存放到第二级缓存的数据？
1 经常被修改的数据
2 财务数据，绝对不允许出现并发
3 与其他应用共享的数据。
我有些问题啊。。
cache不允许并发读？我一直觉得并发读并不会对对象本身造成什么影响吧？请您给我稍微解释一下~谢谢哈。。
对于cache对象与数据库中的同步问题
我觉得利用版本检查的方法也应该是可以处理的啊。。
如果是更新频繁的对象，假设进程b开始运行，获取了version号，进程a进行了一次update,那么在cache中version属性存储的应该是version的新版本，也就是version=version+1，这样因为进程b拥有version的旧版本的值，在进行下一次select或者其他调用查询的时候就会报错了。
那么对于对象来说，关键的问题就是对setter方法进行版本更新。
而在getter中加入版本验证。
然后利用这个对象与数据库进行交互，我觉得应该能解决问题。
我菜鸟。。说的不对狠狠批评。。
关键是假如你用了Cache,你就肯定会遇到从cache中读取的数据和数据库中不一致的情形，因为cache的同步毕竟需要时间，也就是说cache中数据肯定在时间上是落后于数据库中的数据，无论你采取哪种方式。楼上的朋友说的仅仅是对cache更新的比较高效的方法而已。
记得banq的书中曾经写过jive对cache的处理方案。就是第一次仅从数据库中读取ID集合，然后对比cache中的ID集合，更新的仅仅是变化的内容，也就是说并不是cache的彻底重新生成。这样提高了效率。
对于银行或者证券行业这样对数据的实时性要求巨高的行业，对于关键数据的处理，我个人觉得肯定是不能使用cache的，无论是哪种cache方案。
[该贴被rocwo于2007年06月07日 17:13修改过]
什么情况适合缓存那段内容网上随便搜的，有很多
cache原理是把一些不是经常变化的而又频繁访问的内容装进去,然后程序需要查询这些内容的时候,先进cache里找,找不到了才跑数据库去找.命中率高的话,性能提升就比较理想.由于这些内容都是塞在内存中的(配置文件可以配置装多少个对象,超出了是不是放到硬盘),所以容量不能很大.当更新频繁的时候,随着数据库的更新,不断刷新缓存,感觉有点得不偿失.本来一次更新的东西现在需要更新两次,而且还有上锁阻塞的可能.
我对cache不是很了解,自己没用过,只看过一些资料,不过中文资料都有一个特点,互相之间抄来抄去,说的都是很简单的东西.(现在我搞activemq和joram就好郁闷,只能自己啃英文资料)
至于并发访问,没什么问题的。象sybase,访问的时候上的是共享锁,可以在一个数据行页上同时上多个同享锁的，而oracle干脆连锁都不上了,更加没问题.
可能想法不是很正确,各位大侠指点下,谢谢
[该贴被gougou3250于2007年06月07日 19:42修改过]
Because it is all thread-safe in business layer.
One thing should be clear: the conflict resolution normally has two solutions:
1. Lock
2. Multi-version
1 lock has side-effect which lost the performance due to the serialization of everything
2 Multi-version is the solution applied most often in SVN, Oracle etc.
和英文都是半吊子，和同胞说话就不必“洋话连篇”了吧。
试改一例：
Each DB , their transaction systems are different.
--> The transaction systems in each DBMS are different.
I am sorry for the inconvenience I made.
since my company's laptop doesn't allow me to install software as I wish, I can only type english.
[该贴被gh_aiyz于2007年06月19日 10:54修改过]