使用CachedRowSetDataProvider需要解决的问题

本文探讨了在使用CachedRowSetXImpl进行数据缓存时遇到的问题,包括缓存管理、SessionBean膨胀、系统分层困难等,并提出了部分解决方案及测试设想。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 
1、 缓存的问题
CachedRowSetDataProvider是用来封装CachedRowSetXImpl,而CachedRowSetXImpl则是JDBC2.0的CachedRowSet一个实现。通常,在设计的时候,NetBeans会在我们第一次把一个数据表拖到页面的时候会同时产生CachedRowSetDataProvider和CachedRowSetXImpl,前者放在页面(Page)里,后者放在SessionBean1里。把CachedRowSetXImpl放到SessionBean的好处是,可以把数据很方便地缓存到Session里。
我们都知道,把数据缓存到session实现起来比较简单,但弊端也显然而见:
(1)       每个session一个缓存,随着用户量的增加,session的增加,缓存数量也随之增加,非常消耗内存;
(2)       每个session一个缓存,会导致更新缓存的时候数据不能同步,出现的情况往往是,某些用户还能看到已经删除的数据。
目前的解决方法可以是:
(1)       CachedRowSetXImpl还是放到SessionBean里,在页面载入地时候refresh一次,重新从数据库读取数据。但这样的话就失去了原来缓存数据的好处,同时,内存的负担并没有减少;
(2)       把CachedRowSetXImpl还是放到RequestBean里,这样每次访问都会重新读取数据。这样的话就失去了原来缓存数据的好处。
2、 SessionBean管理的问题
我们知道,CachedRowSetXImpl默认是放到SessionBean1的,这样,随着系统规模增大、CachedRowSetXImpl数量的增多,SessionBean1就会变得非常的庞大,维护非常高。
目前解决的方法是把系统分模块,每个模块维护一个SessionBean,这样每个SessionBean就会相对比较容易维护。
3、 系统分层的问题
按照我们惯性的系统分层架构,比较常见的是Action+Service+DAO和Action+Delegate+EJB。
反观Visual Web,每个功能模块都耦合性都很强,比如,Table组件跟CachedRowSetDataProvider关联密切,CachedRowSetDataProvider跟CachedRowSetXImpl关联密切,这样就会导致系统的分层非常难。
不得不提的是,CachedRowSetXImpl是放在SessionBean里,它的相关SQL语句也是发在SessionBean里,而SessionBean是属于Action层次的,所以我们就会发现这里持久层和Action层紧密结合,不可分割。
对于这些问题暂时没有解决方法。
4、 系统测试的问题
按照我们的习惯,单元测试是十分重要的。我们一般是使用JUnit做单元测试的框架。前面我们已经讲到,系统分层比较困难,这就会导致单元测试的困难。每次做一些测试都要启动Tomcat或者Application,测试调试都十分麻烦。
目前还没有解决方法,但有个猜想:编写一个测试Visual Web的框架。
需要用到的工具有:
(1)       JUnit,这个没有什么好介绍的
(2)       spice-jndikit,这是一个开源的JNDI provider。由于CachedRowSetXImpl需要使用jndi,所以需要一个JNDI provider。
(3)       DBCP,数据源provider(连接池)。
(4)       一个通用的继承TestCase的用于初始化Visual Web测试的类
然后我们就可以根据这些对Visual Web程序进行测试。由于Visual Web是不可分层,所以我们的测试从页面层面上测试。
5、可移植性的问题
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值