-
1. Re:
aloubyansky Jun 4, 2004 2:52 AM (in response to ravi-ryali)Just remove read-only and access entities in a transaction.
-
2. Re:
ravi-ryali Jun 4, 2004 1:12 PM (in response to ravi-ryali)I appreciate your response. I am sorry to bug you on this but I have not quite understood the logic here. Do you mean to say that by including the method in a transaction or by not making it read-only, I will have a faster response? Could u please let me know how read-only or a transaction affect read-ahead strategy?
Thank you,
Ravi -
3. Re:
aloubyansky Jun 5, 2004 4:37 AM (in response to ravi-ryali)Read-ahead cache is a per transaction cache. So, it makes sense to preload only the data that is going to be used in the transaction. If there is no transaction then preloaded data is thrown away after the invocation.
read-only in jboss.xml has almost the same effect as running w/o transactions. Read-only instance is not associated with the transaction (hence, is not synchronized at commit), is locked only for the duration of the invocation, and is evicted from the cache at the end of the invocation. It means each invocation even in the same tx will reload the instance from the db.
On-find read-ahead makes sense for read-only instance only if it is accessed once (one invocation) in the transaction: finder preloads the instance, the next invocation on the instance will load data from the read-ahead cache but after this invocation the instance will be evicted from the cache and the next invocation will reload the instance from the db. -
4. Re:
aloubyansky Jun 5, 2004 4:42 AM (in response to ravi-ryali)If you use commit option A then the instance won't be evicted from the cache after a read-only invocation.
-
5. Re:
ravi-ryali Jun 7, 2004 10:26 PM (in response to ravi-ryali)Alex,
Thank you very much for your response. Thanks to you, I could cut down the response time to less than 3 seconds from almost 20 seconds. That is 85% reduction. Like you said, I enlisted the operation in a transaction and used read-ahead. But I was wondering on a couple of things. I am sure you could help me out here too.
1. When I look at the server log, I see SQL statements like the one below,
Executing SQL: SELECT AdvertiserID, Name, Address, AgencyID FROM Advertiser WHERE (AdvertiserID=?) OR (AdvertiserID=?).
This becomes a very ineffcient statement if the page-size grows to 500. 'IN' clause might be very effective there. Is there a way for me to use 'IN' clause there to speed up the SQL statement? Can that be configured?
2. Is there a benchmark as to what is optimal performance? If the performance of CMP is close to retrieving the data using a JDBC call, can I call it the most optimized CMP call? I mean, how much ever I optimize CMP, it cannot be faster than a JDBC call, right?
Your responses will be greatly appreciated.
Thanks,
Ravi -
6. Re:
aloubyansky Jun 8, 2004 3:10 AM (in response to ravi-ryali)1. No, it's not configurable. I might look look at using IN but not in the nearest future unless someone comes up with a patch. But keep in mind that there also are compound primary keys that should still use OR like
(col1=? and col2=?) [or (col1=? and col2=?)]. I would recommend using on-find where possible.
2. CMP is implemented on top of JDBC. So it can't be faster than JDBC in loading data. -
7. Re:
gozilla Jun 8, 2004 3:56 PM (in response to ravi-ryali)Alexey,
read-only in jboss.xml has almost the same effect as running w/o transactions. Read-only instance is not associated with the transaction (hence, is not synchronized at commit), is locked only for the duration of the invocation, and is evicted from the cache at the end of the invocation. It means each invocation even in the same tx will reload the instance from the db.
When CMP handles read-only that way (in option-B), isn't it completelly defeating the usefullness of it ?
Read-only is also used to avoid TX locking.
I can understand purging the cache on TX demarcations, or on exceptions, but why doing it during a TX ?
This change of behaviour between 3.2.1 and 3.2.3 is a performance killer for beans running in B mode.
To get decent performance, we have to go back to TX deadlocks if we cannot go for A mode.
Do I miss something ?
Francois -
8. Re:
myname Jun 8, 2004 4:41 PM (in response to ravi-ryali)Francois,
yes you miss something. You might have a look athttp://www.jboss.org/index.html?module=bb&op=viewtopic&t=49002
and Adrian's commentDon't use commit option B. I know it is the default configuration, but it is stupid.
I do not agree with him, but it seems as if our remarks do not are not really aheard ...
Regards
Volker -
9. Re:
aloubyansky Jun 9, 2004 4:57 AM (in response to ravi-ryali)I think this can be fixed by not evicting read-ahead data (per tx data) when loading instance from read-ahead. In this case, read-only (jboss.xml) instances will be reloaded from read-ahead instead of the database.
I will add a config option for this. -
10. Re:
aloubyansky Jun 9, 2004 5:04 AM (in response to ravi-ryali)The reason for eviction of a instance after a read-only (jboss.xml) invocation is that the transaction might perform mixed read-only and modifying invocations. There is a risk for cocurrent transactions getting uncommitted data.
The fix from my previous post should fix it. -
11. Re:
myname Jun 20, 2004 2:55 PM (in response to ravi-ryali)Alexey,
is that fix already available (and how to use it)?
Regards
Volker -
12. Re:
aloubyansky Jun 21, 2004 2:43 AM (in response to ravi-ryali)Not yet. I will you know when it is.
-
13. Re:
aloubyansky Jun 24, 2004 8:31 AM (in response to ravi-ryali)This is implemented in 3.2.5. There is a new config option <clean-read-ahead-on-load> wich can optionally appear in [standard]jbosscmp-jdbc.xml in and .
The default value in standardjbosscmp-jdbc.xml is false which fixes the problem with re-loading the instance from the db (it's reloaded from the read-ahead cache instead). -
14. Re:
myname Jul 23, 2004 5:58 AM (in response to ravi-ryali)And it works as expected. Thank you, Alexey!
3.2.5 seems very useable to me currently. Good job.
Volker