A store record is the data that an operation wants to store, formatted in a certain way. Each store record is identified by a unique record identifier, which is maintained by the store object. Record identification numbers are always increasing, although they are not guaranteed to be consecutive within a store instance database operation execution (remember that different instances can be simultaneously accessing the database). Each store record has a record mark that keeps the record status and can be used by the forwarder. The Store abstract implementation has the following three record mark values:

These record marks are retrieved from a StoreConstants class that keeps the constant values for the toolkit-provided store implementation (internally set column names, default values, etc).

The toolkit provides the following:

The application working with the Store service (either a JDBCStore class instance or any other user-written service that subclasses from Store or implements the StoreService interface) should always work with the StoreService interface, instead of casting the object returned by the toolkit externalizer to the specific Java type implementing this interface. This makes the application code independent of the actual store service implementation used at any time. During development, you can use a dummy store service that will later be replaced by the real store service. You will only have to modify the toolkit definition files, not the application code, to access the appropriate service instance.

The Store class provides facilities to off-line operations for storing and updating data, and to a forwarder for retrieving and deleting the data when it is processed. Although an operation may need to store its data in more than one STORE table, a Store object works with only one table at a time. Therefore, if the operation needs more than one table to keep its information, it should instantiate several Store objects. When you are designing a teller application, the information to be included in each STORE table is part of that design. You will also need a specific off-line processing policy to determine when the operation information must be added to the STORE table and when the forwarder application will go through all the pending operations and try to execute them.

As described previously, each store record has a record mark that is used by the formatter to determine its status: added, updated, or retrievedForForwarding. These record marks are retrieved from a StoreConstants class.

A retrievedForForwarding mark does not mean that the record has successfully arrived at the host system. The forwarder is responsible for processing records marked as retrievedForForwarding once it receives positive acknowledgment from the host application. In this case, it can delete the record from the STORE table so that the next time it is processed, any retrievedForForwarding record can be sent to the host as potentially duplicated. Each forwarder will decide which criteria to follow.

Store objects are inactive just after instantiation; initially, no connection to the database has been set. The application must first request a database connection from the store instance and then explicitly call the open() message to make it active. A close() message reverts the state back to inactive. Most of the store object operations (for instance, changing the table associated with that store object) can be run only if the store object is active.

See Creating a forwarder application for more information about how the store-and-forward process works.

A store schema is the table where the JDBCStore service keeps the records describing the transactions that could not be executed online.

The structure of the STORE table is defined at table creation time, and is provided as an argument to the table generator method. Two noteworthy columns in the STORE table are: DSERECID, which holds the record identification, and DSERECMK, which holds the record mark defining the record status. The DSERECID column is the primary key for accessing the STORE table. DSERECMK can have the values added, updated, and retrievedForForwarding (referenced by name within the code, but converted to an integer value using the StoreConstants class), while concrete implementations can define more values. The other columns are specified at creation time by passing the column definition, using the same format required by the standard SQL CREATE TABLE statement. The column types allowed are the ones allowed by DB2 when using the JDBC drivers to access the database (see Database services for more information).

The JDBCStoreSchemaGenerator class is an auxiliary class that is used for administration tasks. It allows an application to generate the table for a store schema with the given table name, table schema, and table definition (SQL format).

The store schema is just a way of calling the STORE table. By default, if the schemaName attribute of the Schema Generator is set to a specific value, the Schema Generator tries to create a database schema in the DBMS by using the SQL statement CREATE SCHEMA. If the createSchema attribute is set to false, the CREATE SCHEMA is not executed. For example, when using DB2 UDB for OS/390 as the database management system, the createSchema attribute must be set to false. See Creating the STORE table for information on the attributes that you can use to change the behavior of the JDBCStoreSchemaGenerator.