Here are differences:
- findByKey() does a random search, and try will fetch the row(s) by key from the database if not found in the cache
- Under special circumstances (see below) getRow() is fast, otherwise it does linear search until it finds a row with a matching key and is slow.
- findByKey() is generally faster than getRow()
The Special Circumstance for getRow's Being Fast
A key can be formed from key values or by calling row.getKey(). In the latter case, we store the view object's signature and a row handle inside the key object. The combination of VO signature and row handle is unique for this session/collection. So, if you got the key from the row and pass that key later to getRow(), we are able to do match on the VO signature and use the row handle to look up the row very fast. However in web scenarios where you are using the application module pool, you are not 100% guaranteed to get the same application module instance back on the next request (if load on the pool does not permit us to stay with our heuristic appmodule affinity). Another situation is if you have rexecuted the query in a view object since the time you first got the key from the row. In both of these cases the view object's underlying query collection will have a different signature from the one that existed at the time the row key (with signature and row handle) was "handed out". In that case, getRow() is not fast. It will do a linear search. Hence, if the VO is removed and recreated, or VO is passivated and activated, the row handle will be of no help.
If the row set is of any non-trivial size, I would recommend findByKey().
11:10:29 PM 
|
|
