-
1. Re: Severe (almost unbelievable) caching performance problem
aloubyansky Apr 16, 2005 3:58 PM (in response to colinearl)What JBoss version are you using? This feature http://www.jboss.org/wiki/Wiki.jsp?page=CMPCleanReadAheadOnLoad was added specifically to fix what you complain about.
-
2. Re: Severe (almost unbelievable) caching performance problem
colinearl Apr 17, 2005 11:59 AM (in response to colinearl)We are using JBoss 3.2.7
The feature that you describe helps with CMP beans, but we are having the problem with BMP beans.
Is there a similar facility for BMP? -
3. Re: Severe (almost unbelievable) caching performance problem
aloubyansky Apr 17, 2005 2:25 PM (in response to colinearl)No, there is not. It's possible for CMP because of transaction-local read-ahead cache. BMP beans don't have that.
read-only invocation doesn't associate instances with the transaction in which the invocation is performed. That means after a read-only invocation the instance should be invalidated (unless commit-option A) and re-loaded on the next invocation. Otherwise, there will be a case when cached instance won't be in synch with the database. And THAT would be a bug. With that feature for CMP we can fix this by re-loading the data from the read-ahead cache instead of the database. But for BMP... everything is going to be bean-managed. -
4. Re: Severe (almost unbelievable) caching performance problem
kpaliy Apr 18, 2005 9:26 AM (in response to colinearl)As I understood, the only possible way for BMP (except developing our own cache) is to remove read-only attribute. The only thing I'm not sure is if we'll get additional locks in this case. My understanding is that synchronization in instance-per-transaction bean will be done via instance invalidation in afterCompletion of any other thread, which modifies the same bean. If it's correct, no additional locking appears, so we can done this change safely. Is it correct?