[
https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin....
]
Sanne Grinovero commented on ISPN-3953:
---------------------------------------
+1 for the Hibernate specific approach: the window model has some big drawbacks:
- select count() can be extremely slow (It takes 40 minutes on my local wikipedia)
- needs to lock the full table to be accurate (and you don't have an API to do that)
- if the underlying rdbms doesn't support pagination, it's going to beg for mercy
JPACacheStore should not load all entities in memory
----------------------------------------------------
Key: ISPN-3953
URL:
https://issues.jboss.org/browse/ISPN-3953
Project: Infinispan
Issue Type: Enhancement
Reporter: Emmanuel Bernard
Assignee: Mircea Markus
Today several methods use getResultList() and load either all keys or all entities for a
given entity type in- memory at the same time.
This will likely blow up for big tables.
There are two solutions:
## Use Hibernate's specific features
Hibernate ORM has a session.scroll() method that offers a FORWARD_ONLY scrollable result
set. You can then load data and regularly (every 100?) clear the session before hitting
the next result. This will diminish greatly the memory pressure.
## Use a window model
get the number of entities in the table select count(*)
Then use setFirstResult / setMaxResults to navigate the data with a sliding window and
clear the session every time you move the window.
This won't be as efficient as Hibernate ORM's specific approach but will do the
work except on database that don't support the ability to start the results at the nth
element. Look up Hibernate dialects for more info.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira