[ http://issues.apache.org/jira/browse/IBATIS-174?page=all ] Clinton Begin closed IBATIS-174: --------------------------------
> CacheModel does not support caching null results > ------------------------------------------------ > > Key: IBATIS-174 > URL: http://issues.apache.org/jira/browse/IBATIS-174 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.0.9 > Environment: All > Reporter: Chris Mathews > Assignee: Larry Meadors > Fix For: 2.2.0 > Attachments: CacheModelTest.java > > Currently IBatis caching does not support caching null results. Any null > object placed into the CacheModel will always result in what is interpertated > as a cache miss when it is looked up again. When a null object put into the > cache (by calling CacheModel.putObject()) it is actually entered into the > cache as a CacheModel.NULL_OBJECT (which is fine). However, when the same > object is retrieved (by calling CacheModel.getObject()) the > CacheModel.NULL_OBJECT is translated into an actual Java null value. A null > value being returned by CacheModel.getObject() is considered a cache miss in > the calling code (CachingStatement.executeQueryForList() and > CachingStatement.executeQueryForObject())... this is causing a hard hit to > database unnecessarily. > We are running into this problem while trying to cache a simple holiday table > in one of our applications. The query takes a date a parameter and returns a > row if the holiday exists or null if it does not. Since the vast majority of > days are not holidays and therefore return null, 95% of these statements are > actually hitting the database and basically making the cache for this query > ineffective. > The change to fix this appears to be very simple... > Change line 289 from: > return value == NULL_OBJECT ? null : value; > To simply: > return value; > The code that calls CacheModel.getObject() in CachingStatement already checks > to NULL_OBJECT return values and handles them appropriately so it looks like > this scenario has already been thought through but possibly the above > suggested change was missed. > Attached is a test case that shows the defect and should pass once the above > change is made. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
