脏读的意思是实物一进行更改,事务2在未更改以前读取一次数据,在事务1提交后又读取一次数据造成的数据读取错误吧?。。。
那么用版本控制就能完成避免脏读的java控制,只要对exception进行处理了吧。。

在业务层也应该用这种机制来处理吧?对version进行检查就好了吧。原理一样但是得自己实现,同样在对象池中貌似也有这样的问题吧。。最后就跑到jdon大大们的理念中去了。。

to rainerWJY :
脏读是a事务对数据库进行操作,比如更改数据,还没有提交的时候,b进来读了一次数据,之后a事务回滚,b读的数据就是脏读.消除脏读也很简单,当某个数据行/页拥有排它锁的时候,禁止select操作.
而你说所的乐观锁,是为防止在数据行/页上同时加几个排它锁的情况.我是这样理解的
乐观锁原理就象你说的,我到现在还没明白这东西有什么用.数据库默认不就是禁止对同一数据行/页同时加多个排它锁的么?

to shanghaimin:
我对oracle不熟悉,以前一直用的sybase和mysql.查了下oracle的资料,oracle读的时候并不加共享锁(sybase在读的时候要加共享锁,block排它锁,所以不可以进行写操作),只有写的时候才加排它锁.当数据行有排它锁的时候(维护一个回滚段,里面有锁住的内容),当这时有读操作时,从回滚段里读旧的内容.可能造成数据不一致.并不能说哪一种策略就一定好,无非都是在各种因素下选择一种更加合理的做法.就象数据库范式,时间与空间并不是哪一个一定好,只是取某个平衡点而已.

to gougou3250
抱歉我理解有误了。。把脏读当作不可重复读了。。
你说得很对,其实这也是我经常在想的问题,对于事务处理,如果更新频繁应该采取什么样的方式来进行会比较好呢?

不过对你提出的:
什么样的数据适合存放到缓存中?
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中数据肯定在时间上是落后于数据库中的数据,无论你采取哪种方式。楼上的朋友说的仅仅是对cache更新的比较高效的方法而已。

记得banq的书中曾经写过jive对cache的处理方案。就是第一次仅从数据库中读取ID集合,然后对比cache中的ID集合,更新的仅仅是变化的内容,也就是说并不是cache的彻底重新生成。这样提高了效率。

对于银行或者证券行业这样对数据的实时性要求巨高的行业,对于关键数据的处理,我个人觉得肯定是不能使用cache的,无论是哪种cache方案。
[该贴被rocwo于2007年06月07日 17:13修改过]

rainerWJY,客气了,我跟你一样是个菜鸟

什么情况适合缓存那段内容网上随便搜的,有很多
cache原理是把一些不是经常变化的而又频繁访问的内容装进去,然后程序需要查询这些内容的时候,先进cache里找,找不到了才跑数据库去找.命中率高的话,性能提升就比较理想.由于这些内容都是塞在内存中的(配置文件可以配置装多少个对象,超出了是不是放到硬盘),所以容量不能很大.当更新频繁的时候,随着数据库的更新,不断刷新缓存,感觉有点得不偿失.本来一次更新的东西现在需要更新两次,而且还有上锁阻塞的可能.
我对cache不是很了解,自己没用过,只看过一些资料,不过中文资料都有一个特点,互相之间抄来抄去,说的都是很简单的东西.(现在我搞activemq和joram就好郁闷,只能自己啃英文资料)
至于并发访问,没什么问题的。象sybase,访问的时候上的是共享锁,可以在一个数据行页上同时上多个同享锁的,而oracle干脆连锁都不上了,更加没问题.
可能想法不是很正确,各位大侠指点下,谢谢
[该贴被gougou3250于2007年06月07日 19:42修改过]

I think no need to keep concurrency control in business layer.
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.

shanghaimin,既然用英语,就写规矩了,语法错误满天飞,只能证明您的中文
和英文都是半吊子,和同胞说话就不必“洋话连篇”了吧。
试改一例:
Each DB , their transaction systems are different.
--> The transaction systems in each DBMS are different.

to dunai2004,

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.

英语都真厉害哈...羡慕...

对于缓存,可使用ReadWriteLock来控制访问,可避免脏读。java.util.concurrent.ConcurrentHashMap是一个并发性能非常好的map,很适合用来构建自己的缓存。
[该贴被gh_aiyz于2007年06月19日 10:54修改过]

英语好吗?语法有点问题,不过大概意思还能表达明白!

现在的面试者就喜欢唬人 难道他能解决脏读?