Is your report generated inside a transaction?
It should be, otherwise there is no caching (actually worse, there probably is caching, but it is discarded all the time).
P.S. Damned, I seem to be sounding like a broken record, telling the same story over and over...
Yes. All of this happens in a Session Facade api with a tx attribute of required.
Even the finder method to find the orders has a tx attribute of required.
Is this the typical throughput that we can expect ???
I am still puzzled that only 1000 records can be retrieved per minute if you are assoicating the data with CMP beans....the trace shows that ejbLoad is call for each bean..(record)...
Turn on CMP logging to see which SQL statements are being executed. Have a look at the docs about load-group, preloading etc. The configuration changes should be noticeable in the SQL statements executed.
how do i turn cmp logging>???
I turned on DEBUG messages in log4j.xml...i see the queries but also a deluge of message from all the other components
IS there a way to turn CMP Logging alone????
In your case it would more efficient to use finder instead of CMR. Check out on-line docs Optimized Loading chapter. And lazy-resultset-loading on the wiki.
Reposting XML in the code block
<category name="org.jboss.ejb.plugins.cmp"> <priority value="DEBUG"/> </category>
Thanks For your responses. I deeply appreciate it.
I need one small clarification or confirmation . The CMP query for generating related beans seems to be on each individual entity (i see ejbLoad being called for each entity). In a finder you specify the query to get all the entities and assoicate them with entity bean instances. hence using a finder will be more efficient
Is my understanding right???
Thanks in advance,
ejbLoad will still be called on each instance because it's the spec. And this is not what causes performance problems.
You could also use read-ahead for CMR. But lazy-resultset-loading is not implemented for CMR.
In case of a finder, you just query the database and return results. In case of CMR, besides querying the database container will establish relationships. It's more expensive.
Thanks again for taking time out. It makes more sense to me now.
I used the finder and the performance improved relatively. 730 records in 12 seconds. I have not used Lazy-resultset-loading yet.
However sorry to pester you with couple of yet again follow up questions:
1. Do u know the xDoclet tag for generating lazy-resultset-loading in jboss deployment descriptors??? I could not find one in the docs (xdoc nor jboss).
2. This is an unexpected one. Initially I have put the finder method in the OrderBean instead of in LineItemBean . Interesting enough I was getting a class cast exception when i was type casting the object retrieved from the collection returned by the finder to a LineItemLocal object (see ejb-ql query) and I was getting a class cast exception. When I moved the finder to LineItemBean then it worked. Doesn't the spec say that the collection returned by a finder is determined by the SELECT OBJECT(Type) part of ejb-ql query???
/** @ejb.finder method-intf = "LocalHome" * description = "Find all line Items of a order " * query = "SELECT OBJECT(lineitem) FROM LineItemSchema AS lineitem WHERE fooditem.order.id=?1" * signature = "java.util.Collection findFoodItemsOfGroup(java.lang.String orderID)"
I apologize for pestering you. I would really appreciate if you can further clarify.
sincere thanks again,
I guess, there is no XDoclet tags for lazy-resultset-loading yet as it's a new feature. But I don't know for sure.
You can returned different entity types from ejbSelect methods but not finders.
I had some trouble a while ago when upgrading the jboss server.
This is my Order(afsta)/LineItem(afpos) example which works very well now:
* @jboss.relation-read-ahead strategy="on-find"
public abstract java.util.Collection getAfpos();
public abstract void setAfpos(java.util.Collection afpos);
I use XDoclet-1.2.1 for generating the DDs.