The Discardable Variable builder lets you modify an existing variable so that it is not stored in session.
You can have the variable cached and you can specify the maximum size of the cache. This builder is useful if you have large result data sets and want to limit the size of session data and maximize the number of concurrent users supported on a single server.
Alternatively, you can use paging features to bring in one page of data at a time to reduce the session memory used by result data.
Typically, IBM® WebSphere® Portlet Factory builders use session-scoped variables to store data, for example, the results returned from a service call. If these variables are large, great amounts of session data accumulate and limit the number of concurrent users on a single server. This builder automates the work of discarding, reloading, and caching data that would otherwise be held in session-scoped variables. It is recommended in some very specific scenarios to help reduce session size for an application.
If you consider using this builder, identify the particular variables that are using excessive session memory. You can use session size diagnostic tracing to help find the largest session-scoped variables for an application.
To make a variable discardable, ensure that you have a suitable way to refetch the data when it is discarded. For a service operation, the service operation itself can be called to refetch data. However, if the operation has inputs, ensure that the input values are available whenever the data is refetched.
Consider how Java manages memory and object references. If an object (for example, a large XML result structure) is referenced by any object in a session, it cannot be released and available for garbage collection until the entire session is released. Thus, to release a large object, ensure that you remove all references to that object. The Discardable Variable builder handles releasing a variable value, and it handles releasing the object references that are used for paging through data. However, if other builders create additional references to the discardable data, you must also handle making those references discardable. Otherwise, using this builder provides no improvements in the use of memory.
Impact on sorted data
For variables that are displayed with a sorting user interface (for example, using Data Column Modifier builder), whenever the variable is refetched (because it is no longer in cache, or if caching is disabled), the current sorting state is lost. You must sort the data again. This is a limitation of the sorting support in WebSphere Portlet Factory.
This builder directly supports a simple, size-constrained cache and indirectly supports IBM WebSphere Application Server DynaCache functionality. It does not support cross-user caching; that is still handled with Cache Control functionality.
Cache hits, misses, and data refetch operations are logged in server statistics. To obtain additional server statistics detail that shows each model and variable name, enable with the following property setting:
If cache is used for a particular variable and if the cache size for the variable is changed, restart the server to have the new size take effect.
The default cache implementation is Dynacache when the application runs on WebSphere Application Server or WebSphere Portal server. In other environments, for example, WebSphere Application Server CE, DynaCache is not available, and a WebSphere Portlet Factory cache implementation is used.
You can supply the cache implementation by a custom class. Use a new VariableCache
implementation by setting the following property to the name of a class that extends the VariableCache
DynaCache supports a time-to-live setting which controls when data can be released from cache. The WebSphere Portlet Factory cache implementation does not support this feature. Control the time-to-live setting with the following property.
The value is in seconds.
Parent topic: Builder help
About using the builder call editor