Okay,
I have tested and made for now these configs to deal with so much data:
In my properties-file: The "second level cache" should be disabled programmatically
as you do not need to disable the cache in all scenarios:
Now, let s look at all CRUD-Operations: For SAVE-Operation: - after flush,
you should call clear,
to clear the cache (first level cache? clear all references?)
public void save()
for (int i=1; i<= 2000000; i++)
{
Item i = new Item();
entityManager.persist(i);
entityManager.flush();
// but when I clear within the loop, does hibernate.jdbc.batch_size works?
// I flush and clear after I saved one record..so there can nothing be //batched, am I right? entityManager.clear();
}
For READ-Operations: - the only thing, I know, is to set the boundaries of your selection.
If you "set first result" to 0 and "max result" to 2000,
then the list result returns the first 2000 records (when I call this method again from the same session (?), then it returns the result-list contains the records from 2001-4000 (and so on). Am I right??
- the other thing, I know, is that when you call getReference, then you have NO database-hit:
public void read() {
// but reference works only, if this item is in my cache. Am I right?? Item i = i.getReference(Item.class, 1);
}
For DELETE-Operations: I guess, delete is fast enough(am I right? Are there any optimizations there, too?)
For UPDATE-Operations: What for optimizations exists for update-statements?
This thread should summarize all optimizations-strategies which can (should) be made by handling millions of datas. Any suggestions. practical experiences or best-practices are very welcome:-) We can categorize it at follows: Category 1: Optimizations in: properties.xml
Category 2: Optimizations in: CRUD-Operations
Category 3: Optimizations in: ?)
[ December 15, 2008: Message edited by: nimo frey ]
