j2ee架构设计中需要注意的一点（1）

     我们做j2ee系统时往往会遇到要进行用户的登录验证等问题，同样也要涉及到用户登录次数和登录时间等信息的记录和统计的问题，往往我们的做法是在用户表中增加两个字段，一个是登录次数（login_count），另一个是最后登录时间（last_login_time），然后在用户每次登录的时候去update用户的这条记录，登录次数＋1，登录时间改为当前的时间。

      在用户两很小且用户对系统的性能要求不是很高的时候，那么我们采用这种方式的处理是没有错的，但是遇到高并发用户量情况的时候怎么办呢？我们曾做过一个小小的压力测试，使用一组帐号（10个）不停的对上面的设计进行压力测试，结果发现，系统在压到200的时候就崩溃了，服务器硬件什么的都是没有问题的：机器是hp-unix（惠普服务器中比较高端的机型了），两台oracle10 db，共享一个数据盘阵，两台weblogic 9 服务器，4个server节点。

      问题就出在数据库，而且还不是数据库本身的问题，是我们拙劣的程序设计和程序，在多个客户端在同时操作一条数据的时候，oracle性能再强大也无济于事，出现了死锁。

死锁的条件
互斥条件（Mutual exclusion）：资源不能被共享，只能由一个进程使用。
请求与保持条件（Hold and wait）：已经得到资源的进程可以再次申请新的资源。
非剥夺条件（No pre-emption）：已经分配的资源不能从相应的进程中被强制地剥夺。
循环等待条件（Circular wait）：系统中若干进程组成环路，改环路中每个进程都在等待相邻进程正占用的资源

 诊断系统中的锁

为了找出系统中那些用户锁住资源以及那些用户在等待相应的资源，可使用以下语句(其中的/*+ NO_MERGE(..) */千万不可省略, 否则会很慢)：

-- looklock.sql
-- use the NO_MERGE hints can speed up the query
select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ 'Wait' "Status", a.username, a.machine, a.sid, a.serial#, a.last_call_et "Seconds", b.id1, c.sql_text "SQL"
from v$session a, v$lock b, v$sqltext c
where a.username is not null
and a.lockwait = b.kaddr
and c.hash_value =a.sql_hash_value
union
select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ 'Lock' "Status", a.username, a.machine, a.sid, a.serial#, a.last_call_et "Seconds", b.id1, c.sql_text "SQL"
from v$session a, v$lock b, v$sqltext c
where b.id1 in
(select /*+ NO_MERGE(d) NO_MERGE(e) */ distinct e.id1
from v$session d, v$lock e
where d.lockwait = e.kaddr)
and a.username is not null
and a.sid = b.sid
and b.request=0
and c.hash_value =a.sql_hash_value;

 附：解除锁

alter system kill session 'sid, serial#'; 

 

以上也是个人的经验之谈，可能有不妥之处，也请大家斧正，当然如果您有更佳的方案，也希望您不吝赐教。