christian wrote:
No, not out-of-the-box. This would also imply that your complete second-level cache is fully transactional and not give you much performance benefit. Session size certainly is an issue, but are you really sure that this affects you? Do you have benchmarks that show that this is a problem?
No, we're just at the start of a large project, so no experience/benchmarks yet.
We do have the amount of RAM to hold the whole active part of the DB in memory, and reads outnumber writes by a factor of 10 (estimated) or more. So a large cache should be of great benefit. However, individual user sessions may use a significant amount of total RAM (say 10%), so already 10 parallel user sessions would double the amount of used RAM simply by creating copies of objects that are not likely to be modified. That is quite a waste; it would be very nice if it could be avoided. Not only because of RAM usage, but also because of the strain it puts on the garbage collector.
The alternative would be to use one session for the small editing stuff, and use other session with flush/clear (or even bypass hibernate alltogether) for producing large lists of objects. Do you think the latter is the only way?
Thanks for any insight.