Understand SDOResultSet stateless mode
- Last Updated: January 16, 2024
- 3 minute read
- OpenEdge
- Version 12.8
- Documentation
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 application server
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 application server and updates are sent to the application server. After that
interaction, the ProcObject is released and the SmartDataObject persistent procedure is
deleted.
Stateless mode is with a stateless application server, the Stateless mode for SDOResultSet is orthogonal to the operating mode
of the application server. The client can set the SDOResultSet to Stateless mode even if the application server is not running in stateless
operating mode. The client also can create a non-stateless SDOResultSet to access a stateless
application server.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:
- Only batch updates are allowed. For more information, see Use batch mode [extension].
- Stateless mode is only allowed with the
PREFETCHscrolling mode. For more information, see Understand SDOResultSet scrolling modes.
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 Miscellaneous management 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 specifiedrowId, 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 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.