It seems as if the PersistentList class pads its list with null values up to the index value of the first item being added. In our application, that item could have an index of over 1 million which causes 999,999 null entries to be added to the list. Heap analysis shows this list to be in the 11mb range which is quite a difference than the expected 800 bytes (4 list items @ 200 bytes each). Couple that with the fact that when you try to leverage caching, two copies of the list are kept, we are seeing a 23-24m object that should only be around 30k if you include the parent.
This was initially identified on 3.2.2 but it looks like 3.6 has the same code. Hopefully I am missing something really simple or there is some other way to use second level caching in the context of list associations that is a bit less memory intensive.
Any advice much appreciated.
Regards,
Chris
Code:
public Object readFrom(ResultSet rs, CollectionPersister persister, CollectionAliases descriptor, Object owner)
throws HibernateException, SQLException {
Object element = persister.readElement( rs, owner, descriptor.getSuffixedElementAliases(), getSession() ) ;
int index = ( (Integer) persister.readIndex( rs, descriptor.getSuffixedIndexAliases(), getSession() ) ).intValue();
//pad with nulls from the current last element up to the new index
for ( int i = list.size(); i<=index; i++) {
list.add(i, null);
}
list.set(index, element);
return element;
}
Login
FAQ
Search