The problem was probably a nested select that kept loading the same object, but it could also be that you're keeping references to these objects somewhere outside of iBATIS (thus caching will just delay the problem).
But as for memory usage for any given request, iBATIS 3 has a 2 stage cache that will avoid multiple calls to the same statement within a single session (and also solves circular relationships). Cheers, Clinton On Wed, May 7, 2008 at 12:52 PM, Harvey Kim <[EMAIL PROTECTED]> wrote: > Interesting.... That is what I assumed. But I was on occasion getting > outOfMemory error. Taking out groupBy helped but it still hit > outOfMemory problem on occasion. Just for kicks, I added LRU caching > with size of "1" and all my memory problems went away. This goes back > to the RowHandler outOfMemory problem I've been whining about. Anyway, > now I can run that thing for days and one specific scenario that always > created outOfMemory error disappeared. Also, when I print out the > available memory, it is constant. It no longer decreases with every > iteration. And the only change is that I added the cacheModel-LRU with > size of 1. I can finally rip that ugly JDBC code and go back to > ibatis!!! What a relief! But I no longer have outOfMemory problem. > In short => eliminate groupBy and add cacheModel LRU with size of 1 = > smooth sailing. Just something to ponder. > > thanks much... > > On Wed, 7 May 2008 11:43:56 -0600, "Larry Meadors" > <[EMAIL PROTECTED]> said: > > The default behavior is no caching. > > > > Larry > > > > On Wed, May 7, 2008 at 11:38 AM, Harvey Kim <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > If cacheModel isn't specified for a given select statement, can > somebody > > > tell me what mechanism ibatis uses to do caching (if any)? Meaning, > > > what is the default behavior. > > > > > > thanks in advance > > > > > > -- > > > http://www.fastmail.fm - IMAP accessible web-mail > > > > > > > > -- > http://www.fastmail.fm - One of many happy users: > http://www.fastmail.fm/docs/quotes.html > >
