The SDOResultSet Stateless mode allows the client to scroll through and update data without maintaining an active persistent procedure on the Application Server process. Its primary value is in support of an AppServer running in the stateless operating mode. In this operating mode, maintaining a persistent procedure on the Application Server process binds the process to the client, making it unable to serve other clients.
In Stateless mode, the underlying ProcObject (mapped to the SmartDataObject) is held only for the short duration when more data is fetched from the AppServer and updates are sent to the AppServer. After that interaction, the ProcObject is released and the SmartDataObject persistent procedure is deleted.
Note: Although the most useful application of Stateless mode is with a stateless AppServer, the Stateless mode for SDOResultSet is orthogonal to the operating mode of the AppServer. The client can set the SDOResultSet to Stateless mode even if the AppServer is not running in stateless operating mode. The client also can create a non-stateless SDOResultSet to access a stateless AppServer.
An SDOResultSet is in Stateless mode if setStateless(true) is called on the SDOParameters of the _createSDOResultSet() class factory method.
The SDOResultSet Stateless mode has the following limitations:
As with any SDOResultSet opened in PREFETCH mode, Stateless mode causes the SDOResultSet to return all its rows to the client application at one time. This can pose performance problems for very large ResultSets. To manage an SDOResultSet created in PREFETCH mode, you can explicitly set the maximum number of rows fetched for a query by using the SDOParameters.setPrefetchMaxRows() method. Typically, you use this method together with the SDOResultSet.reOpenQuery(String rowId) method to limit the number of rows fetched for any one query and fetch the next set of rows for a different instance of the query. (For more information on the reOpenQuery(String rowId) method, see Miscellaneousmanagement methods.) Thus:
The SDOParameters.setPrefetchMaxRows() sets the maximum rows to fetch for the query when the SDOResultSet is created
The SDOResultSet.reOpenQuery(String rowId) fetches a new set of rows, using another instance of the same query and maximum number of rows, but starting from the specified rowId, which identifies one of the rows in the previous instance of the query
The following block of Java code uses these two methods to manage the fetching of rows for a stateless SDOResultSet:
// The code shows the fetching of 19 rows in two batches under
// the Stateless mode.
SDOParameters params = new SDOParameters();
params.setStateless(true);
while (rSet.next())
{ System.out.println(
rSet.getObject(1)) + " " +
rSet.getObject(2) + " " +
rSet.getObject(3));
lastRowid = rSet.getRowIdentity();
}
// Get 10 more rows starting at lastRowid
rSet.reOpenQuery(lastRowid);
// Skip the row we already visited
rSet.next();
// Displays the next 9 rows.
while (rSet.next())
{ System.out.println(
rSet.getObject(1) + " " +
rSet.getObject(2) + " " +
rSet.getObject(3));
}
The code sets the maximum number of rows to fetch to 10 and creates the stateless SDOResultSet, rSet, to access the SmartDataObject, CustSDO.w. It then fetches the rows, maintaining the last-fetched row ID in lastRowid. Finally, it uses lastRowid to reopen the query and fetch the next 10 rows.
Because you must use the last-fetched row ID as the starting point, this causes the same row to be returned as the first row in the next query. The code thus uses the next() method to skip the already-visited row, and it fetches the next 9 rows that have not yet been fetched, for a total of 10 returned for the query.
Only batch updates are allowed. For more information, see Using batch mode [extension].