By nested results, yes, I mean collections and associations. And by
"flattening" I mean avoiding the use of those.
iBATIS exhibits this behavior, the same way any ORM would, because the
object instances need to be cached to preserve object identity. So as
you're result set is being read through, each unique object is stored.
iBATIS isn't quite as effcient as something like Hibernate can be with
circular references though, in that depending on how you map it out, you may
end up with multiple instances of the same data (parent/child relationships
mapped with resultMap).
So with iBATIS, the most memory efficient approach is to use nested select
associations/collections. But for query performance, nested resultMaps are
ideal. I often find I need to use a combination of both to get the best
optimization. But if I often don't load lists of complete objects either.
If I'm loading a large list, I'll use a lighter weight representation, and
then only load the complete object graph for individual instances. I've
never found a case where this wasn't a good idea anyway. Even when working
with something like Rails, a rich domain ORM, I would often write optimized
lightweight queries for large lists of flatter objects.
The memory should not be significantly more than will ultimately be required
to store your final result set. And any additional memory used should be
released upon the closing of the SqlSession.
If the memory isn't being released at the end of the session, that's a
different story... but otherwise, this is normal behavior.
Clinton
On Thu, Jan 14, 2010 at 11:20 AM, Dave Rafkind <dave.rafk...@gmail.com>wrote:
> Thanks for the reply. What do you mean by nested result maps or selects? Do
> you mean collections or associations with their own selects and result maps?
> Why would ibatis exhibit this behavior in that case?
>
> And by flattening, you mean the same kind of stuff used to avoid the n+1
> select problem?
>
> On Thu, Jan 14, 2010 at 1:02 PM, Clinton Begin <clinton.be...@gmail.com>wrote:
>
>> If it uses nested result maps or nested selects, I'm afraid you're out
>> of luck. You'll need to reduce the query results, or flatten out the
>> results.
>>
>> Clinton
>>
>> On 2010-01-14, Dave Rafkind <dave.rafk...@gmail.com> wrote:
>> > Hi ibatis list, I'm new to ibatis so perhaps this is a noob question.
>> I'm
>> > using Ibatis 3 (ibatis-3-core-3.0.0.216.jar) with a somewhat complicated
>> > schema (plenty of circular links etc).
>> >
>> > I'm doing something like this:
>> >
>> > List<MyIdObject> ids = session.selectList("getAll");
>> >
>> > for (id : ids) {
>> > MyObject o = session.select("getOne", id.getActualId());
>> > }
>> >
>> > The first query returns a list about 2k big, and the second query in the
>> for
>> > loop returns objects that are somewhat large (have several collections
>> in
>> > them, a discriminator, etc).
>> >
>> > The problem I have is that as the for loop marches on it uses an
>> > ever-increasing amount of memory. I would assuming that when the objects
>> in
>> > the body of the for loop go out of scope they can get garbage collected,
>> but
>> > apparently that never happens; is there some weird interaction with the
>> > "first-level cache"? Should I be going about this a different way?
>> >
>> > Thanks!
>> > Dave
>> >
>>
>> --
>> Sent from my mobile device
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>
>>
>
