[url]http://www.iteye.com/my_topic/35309[/url]
[quote="partech"]前些天测试中发现,缓存好像不能处理数据变更的情况。原来还是好好的阿。
经过跟踪,发现问题出在UpdateTimestampsCache,不知哪位仁兄手快,改了一行if语句,把原来正确的逻辑改错了。在7月13号到11月15号之间,下载的hibernate都有这个BUG。
代码
1. return lastUpdate.longValue() < timestamp.longValue();
2. if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;
从这件事情,引申出另外一个问题,测试是如何的重要。
如此重要的特性在四个月后才得以修复,应该说hibernate的测试工作是有问题的。至少,在多对象连接的情况下,缓存没有测试。
没有测试的代码就是这样可怕,浪费时间和精力不说,还打击了信心。
所以说,测试工作怎么强调都不过分阿。
[/quote]这个错误简直是不可原谅的。
不过就此也引出一个问题,在循环里直接return返回值,虽然语法上没问题,但是就逻辑而言,很容易出错。像这个错误的产生,就是由于修改代码的人,简单的认为[code]if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;[/code]等价于[code]return lastUpdate.longValue() < timestamp.longValue();[/code],而没有看清楚原代码中当lastUpdate>=timestamp时,是不会跳出循环去return的。
严格一点来说,方法的返回值,是否应该在方法体的最后统一提交更好一些呢?而不要在方法中出现很多的return。
另外采用缓存策略还有一点不知如何处理为好,就是当缓存已经存在的时候,服务器的系统时间被回退,这样lastUpdate时间就可能小于timestamp,但实际上缓存应该是被更新的。这种可能性不是没有的。
是否可以这样来处理,每次的操作均在系统中记录最后一次的操作时间,一旦新的系统时间小于上次操作时间,则系统终止运行,并报错。类似某些有试用时间限制的软件防破解一样,即使把系统时间改回,也一样无法继续试用。
[quote="partech"]前些天测试中发现,缓存好像不能处理数据变更的情况。原来还是好好的阿。
经过跟踪,发现问题出在UpdateTimestampsCache,不知哪位仁兄手快,改了一行if语句,把原来正确的逻辑改错了。在7月13号到11月15号之间,下载的hibernate都有这个BUG。
代码
1. return lastUpdate.longValue() < timestamp.longValue();
2. if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;
从这件事情,引申出另外一个问题,测试是如何的重要。
如此重要的特性在四个月后才得以修复,应该说hibernate的测试工作是有问题的。至少,在多对象连接的情况下,缓存没有测试。
没有测试的代码就是这样可怕,浪费时间和精力不说,还打击了信心。
所以说,测试工作怎么强调都不过分阿。
[/quote]这个错误简直是不可原谅的。
不过就此也引出一个问题,在循环里直接return返回值,虽然语法上没问题,但是就逻辑而言,很容易出错。像这个错误的产生,就是由于修改代码的人,简单的认为[code]if ( lastUpdate.longValue() >= timestamp.longValue() ) return false;[/code]等价于[code]return lastUpdate.longValue() < timestamp.longValue();[/code],而没有看清楚原代码中当lastUpdate>=timestamp时,是不会跳出循环去return的。
严格一点来说,方法的返回值,是否应该在方法体的最后统一提交更好一些呢?而不要在方法中出现很多的return。
另外采用缓存策略还有一点不知如何处理为好,就是当缓存已经存在的时候,服务器的系统时间被回退,这样lastUpdate时间就可能小于timestamp,但实际上缓存应该是被更新的。这种可能性不是没有的。
是否可以这样来处理,每次的操作均在系统中记录最后一次的操作时间,一旦新的系统时间小于上次操作时间,则系统终止运行,并报错。类似某些有试用时间限制的软件防破解一样,即使把系统时间改回,也一样无法继续试用。