[EMAIL PROTECTED] wrote : Can you enable this in Hibernate to see if that
solves the problem:
|
| hibernate.cache.use_minimal_puts
|
| Gavin and I have had a discussion on the potential problem. That, when
using query cache, Hibernate will do a put on the JBossCache while retrieving
Can you enable this in Hibernate to see if that solves the problem:
hibernate.cache.use_minimal_puts
Gavin and I have had a discussion on the potential problem. That, when using
query cache, Hibernate will do a put on the JBossCache while retrieving from
db. This can cause a long lock that
So here's my understand how Hibernate uses the 2nd level cache (disclaimer: I'm
not a Hibernate expert).
And I haven't read the docs yet...
- 1st level cache is per Session. This is an Object-level cache
- 2nd level is per VM, shared by all Sessions. This is a row-based cache
- When an object is
Neither READ_COMMITED nor READ_UNCOMMITED help, only NONE which is
inappropriate.
I do not claim it's cache's bug, but it appears to be some design issue.
Let me explain. Suppose you have some read-only entity which is frequently used
through application. This is exactly where I expect to take
[EMAIL PROTECTED] wrote : So here's my understand how Hibernate uses the 2nd
level cache (disclaimer: I'm not a Hibernate expert).
| And I haven't read the docs yet...
|
| - 1st level cache is per Session. This is an Object-level cache
| - 2nd level is per VM, shared by all Sessions.
The problem is concurrent access to the same data from multiple transactions.
Since we're using pessimistic locking in JBossCache, some of the transactions
will time out trying to acquire locks held by other transactions.
Until we implement optimistic locking, here's what you can do to work
This is serious problem if it is from cache. But I don't get what are you
trying to say in the last couple sentences? And the log output also doesn't
make sense to me either.
Can you elaborate more? Also, do you think you can create a JUnit test case to
see if you can reproduce purly from
