|
Problem |
Performance optimization for EJB finders complicate how
finder methods are processed. |
|
Solution |
Normally, the EJB container in the WebSphere® Application
Sever versions 4.0.x and 5.0.x attempts to do one of the following:
- Use the currently-specified transaction when a bean method
is executes
- Create a transaction if transaction attributes allow
- Create a local transaction to ensure a context is present
if possible
There are cases when some sort of transaction context might not be
present, but not in the common cases.
This finder scenario gets more complicated because there are performance
optimization considerations.
When a finder is run, a choice is made to get a greedy or
lazy version of the enumerator.
In the lazy enumeration code path, only the first 25 items are
retrieved. If things proceed as expected, and you need an item from the
next set of 25 (and from every subsequent set up to the maximum number of
items returned), the hasMoreElements() method triggers a set of calls that
gets the next set of 25. However, if the calling transaction ends before
the end of the first set of 25, or any following set of 25 is retrieved,
the remainder is not made available.
There is a special case for a greedy enumerator. That is a
construct that gets all the items, and does not limit the fetch size.
If the transaction is created in the finder method's scope (for example,
during the WebSphere EJB container's preInvoke processing), WebSphere
returns a greedy enumerator. Otherwise, it returns a lazy enumerator.
Identifying the situation
- A trace helps to determine the details of the situation.
Enable the traces using the following trace string:
-
com.ibm.ejs.container.*=all=enabled:com.ibm.ejs.persistence.*=all=enabled:com.ibm.ejs.csi.*=all=enabled
- Verify the Tx settings of the EJB's finder method (all
home methods in case override is in place, and so forth), both of the
actual finder methods and any methods that call it, if that is the
scenario you are considering.
|
|
|
|
|
|
|