Hi,

yes the listDataProvider doesnt help for minimize memory usage. The DataProvider will be stored in Component and therefore all fields are also stored in component/session. For e.g. 2000 Session you have 2000 times the same list in memory. This is not what you want. First optimization: Cache the list in one list (static or cacheprovider), that only one session is referenced in all dataprovider. Later optimization: dont hold a reference to the list und load the list on every request in dataprovider but with limiting the e.g. SQL-Query to the (first, count) Range given in DataProvider. The list and items will be detached on end of request (which means removed from memory)
SQL-Query caching is also recommended.
MySql supports this by "limit" .

Note: Hibernate and JDO supports rangequeries DB independent.

Every Request will be in Young-Gen Memory and shortly removed after requests ends.
You have full controll what will stored in memory(Caches)

cya
   Martin

kshitiz schrieb:
Hi,

Thanks for the reply. I am trying t achieve what you suggested me. But one
thing I want to ask. In listDataProvider, you will anyway provide list of
data to get rendered. You may render it in any manner but that list will be
stored as final or class variable. Wont that take up the session ? I mean
what difference will it make to use dataview instead of simple list with
listview in terms of memory? I am trying to understand its concept so please
ignore my mistake...:)



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Should-I-really-go-for-LoadableDetachableModel-tp4651353p4651356.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to