-
1. Re: Transaction "Supports" causes NULL Pointer in getApplic
dsundstrom Apr 29, 2002 4:26 PM (in response to soeiro)Change it to Required. JBossCMP does not support non-transactional entities.
-
2. Re: Transaction "Supports" causes NULL Pointer in getApplic
soeiro Apr 30, 2002 12:29 PM (in response to soeiro)Dain
I have reverted the transaction to "Required", but I was trying to get things to run more quickly. Do you have any suggestions? The way it is now, it needs about 1 second to process only two methods: getName() and getAlias(). There is a Session Bean that reads about 800 entities (with findAll()) and then iterates through all of them to populate a list box (methos getName and getAlias). That's more than 10 minutes to show the first screen!
Ok. I don't know what could be done that doesn't require throwing out our Object Model and using plain SQL queries for this. However, there are other situations that we would greatly like to preserve the Object Model.
This method doesn't need to have transactions and could use caching and anything else that could speed it up a bit. We changed the standarjbosscmp-jdbc.xml to limit the cache to just 1 entry, but at each getXX it executes the folwing SQL statement:
DEBUG [] Invoke: [1] getName()
DEBUG [] Executing SQL: SELECT ID_ORGAO,NAM_ORGAO, ALS_ORGAO, ID_SUPERIOR FROM ORGAO WHERE (ID_ORGAO=?) OR (ID_ORGAO=?) OR ... 253 times
DEBUG [] Invoke: [1] getAlias()
DEBUG [] Executing SQL: SELECT ID_ORGAO,NAM_ORGAO, ALS_ORGAO, ID_SUPERIOR FROM ORGAO WHERE (ID_ORGAO=?) OR (ID_ORGAO=?) OR ... 253 times
Since the caching that it is using ins't working (it issues the same command again for each of the 800 entities), how could we turn it off? At least we could have ejbLoad() working a bit faster if it only loaded one entity for each call (instead of 255 entities, as it seems).
Thanks,
Luis JB Soeiro -
3. Re: Transaction "Supports" causes NULL Pointer in getApplic
dsundstrom Apr 30, 2002 12:58 PM (in response to soeiro)You have put JBossCMP in the worst possible loading senario. You have read-ahead on (by default) and you are accessing your bean using many micro transactions. This causes JBoss to load lots of extra data and immedately throw that data away, as the data is only valid for the length of the transaction.
Wrap all of you access to the entity in a single transaction, and it will be much faster. If you don't want to do this, set the read-ahead strategy to none, but his will be much lower then using optimized loading. -
4. Re: Transaction "Supports" causes NULL Pointer in getApplic
soeiro Apr 30, 2002 1:41 PM (in response to soeiro)Dain
Thanks. Just by calling from a "Required" transaction method, total time decreased from 10 minutes to 13 seconds. Could you state briefly what are these values?
<read-ahead>
on-load
10000
<page-size>1000</page-size>
<eager-load-group>*</eager-load-group>
</read-ahead>
<list-cache-max>100000</list-cache-max>
I assume they are not measured in bytes, but in pages (and page is measured in bytes...). Do they have any limit to what it would become less effective? For example, seeting above X would just passivate everybean because of shortage of memmory Y.
Thanks again, this saved the day.
Luís JB Soeiro -
5. Re: Transaction "Supports" causes NULL Pointer in getApplic
dsundstrom Apr 30, 2002 11:39 PM (in response to soeiro)From the dtd:
<!-- Specifies the read ahead strategy. <read-ahead> <strategy>on-load</strategy> <page-size>255</page-size> <eager-load-group>*</eager-load-group> </read-ahead> --> <!ELEMENT read-ahead (strategy, page-size?, eager-load-group?)> <!-- Specifies the strategy used to read-ahead data in queries. The strategy element must be one of the two following: <strategy>none</strategy> <strategy>on-load</strategy> <strategy>on-find</strategy> --> <!ELEMENT strategy (#PCDATA)> <!-- Specifies the number of entities that will be read in a single read-ahead load query. --> <!ELEMENT page-size (#PCDATA)> <!-- Specifies the number of simultaneous queries that can be tracked by the cache for an entity. --> <!ELEMENT list-cache-max (#PCDATA)>
list-cache-max may need more documentation. JBossCMP tracks the order of entities loaded from a query, and the order is used in the on-load strategy when loading the next 'n' entities. The assumption is you are iterating over the results in forward order.