A lot of people hit performance problems in BC4J when they, either on purpose or inadvertently, query thousands of rows into a view object. One classic mistake I see is that developers call the getRowCount() method on their rowset instead of getEstimatedRowCount(). There's a big difference. The getRowCount() gives you an exact count by fetching all the rows, then telling you how many you have. The latter issues a separate SELECT COUNT(*) query and tells you how many rows the query will return (it's an "estimate" since technically speaking, if another transaction commits a new row that qualifies for your where clause between the time you get the estimated count and the time that you iterate the actual results, the count could be slightly off).
I try to explain the side effects of caching a large number of view object rows in this Overview of Temporary Tables Used by BC4J paper. It describes the BC4J "view row spillover" feature to protect against unbounded memory usage when the number of cached view rows crosses a configurable boundary, and describes how to disable the feature if you didn't mean to be using it.
In BC4J 9.0.4, we've turned the view row spillover feature off by default instead of on since in practice, the default settings in previous releases have caused more surprises for developers than we'd anticipated.
12:13:01 AM 
|
