ListDataProvider and VM use up memory

[tong123123]

for using LIstDataProvider, if the search result contains many records and many users use similar criteria to search simultaneously, it will use up the memory of the server JVM easily, is this correct?
So for searching record with large result, we should use celltable with pager and data provided by AsyncDataProvider so can break down the search result in server into smaller size, is this correct?
For example,
if the search criteria return 10,000 record at once time using ListDataProvider and if 500 ppls search using same criteria simultaneously, the server JVM memory will use up.
So if using AsyncDataProvider, each time the search result is smaller (from onRangeChange) and so the chance of used up the memory in the server JVM is decrease, is this correct?

[tong123123]

the title VM means server JVM.

[RickL]

A ListDataProvider does not use memory on the server JVM, it resides on the client.

That said, an AsyncDataProvider and a pager would be far better than reading 10,000 rows at once from the server into a ListDataProvider (which would use a lot of memory on the client AND generate a ridiculous amount of network traffic and latency).

That's the point of AsyncDataProviders and pagers, to get what the client can "see" when, and only when, the client wants to see it.

[Ümit Seren]

Exactly for that reason there are server-side caches. 

Just set up a second level cache (ehcache, etc) and that should solve your scaling issue. 

If you use Spring as a backend technology it's a couple of configuration lines to add second level cache for 

Apart from caching there is the question if it really makes sense to transmit 10.000 records to the client. Mostly your users will just search in this huge list. 

The advantage of transmitting everything at once is that you can search exclusively on the client and you won't need any request to the server. However serializiation and de-serialization of 10.000 records will take some time and it will also increase memory consumption on your browser. 

You can also go a hybrid approach. Transfer around 2.000 rows using a AsyncDataProvider and once your search criteria is that specific that you have all the records at the client side you can do client side filtering (but programming-wise that's a little bit more involved)

[Kei Kei]

Sorry, what is server-side caches and second level cache?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Ol1vgB5r9FAJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Ümit Seren]

Hibernate has a first level cache which is caches object for the duration of the session.
However in your case multiple users may access the same list and this might happen the context of different sessions. For that reason you can use second level caches:

See here:

http://www.javalobby.org/java/forums/t48846.html

http://ehcache.org/documentation/user-guide/hibernate