 |
Thursday, February 13, 2003 |
The API findByKey() on our oracle.jbo.RowIterator interface takes two arguments: a Key, and an integer number indicating the maximum number of rows you expect to retrieve. The reason is supports specifying this number is that we support providing a "partial key" for multi-attribute keys where you can leave one or more parts of the key null. Doing so will leave that attribute in the key as a "degree of freedom", and potentially result in returning more than one row.
However, if you know you are already providing a completely populated Key object that will uniquely identify a row, make sure to specify the number one (1) for the 2nd argument to findByKey(). That will avoid an extra trip to the database to go see if there are more matches.
9:33:25 AM 
|
|
"Is there any way to turn off the spillover mode for application module pending state?"
"View Row Spillover" and "Pending AM State Snapshop" are two different features.
They both use the database on the "internal connection" to manage state of some kind, but the features are orthogonal.
That is, you can have the "view row spillover" feature kick in even for a stateless application module if you iterate and cache thousands of view rows.
You can have the Pending AM State snapshop if you have a "stateful" AM usage, even without ever querying rows. For example, over subsequent page request you could be creating multiple new "expense report items", or something.
Turning off view row spillover is documented further in this article http://otn.oracle.com/products/jdev/htdocs/bc4j/bc4j_temp_tables.html and in 9.0.4 we've changed the default to be disabled instead of enabled.
- If you use AM's in "Stateless" mode, you won't have any state snapshotting for the obvious reason that you aren't asking us to manage any pending state for you.
- If you are using a "stateful" AM, to the best of my knowledge the only way to completely prevent AM snapshotting is to run with "failover mode" turned off, and to use an AM pool sized correctly to handle the number of simultaneous ongoing user sessions with pending state. In this way, our "Stateless with Affinity" algorithm would never need to utilize an AM instance in the pool for a session that was different from the one who began the "Stateful" interaction with it.
Consult the online help system for a description of all of the BC4J system parameters that affect the sizing of the application module pool.
The default is for failover to be enabled.
7:05:27 AM
|
|
© Copyright 2008 Steve Muench.
|
|
