Coordinating DB2, OAM, and your application

OAM uses DB2 databases to contain descriptive information about every object that is stored. OAM does not commit the descriptive information written to that DB2 database; the application using OAM must perform that function. This allows the transaction to correlate and synchronize OAM’s activity with other activity in the application (for example, synchronization of an application’s and OAM’s permanent database changes, or alternatively, synchronization of backing out of those changes).

Note: When objects are stored directly to the file system sublevel from an application program the application must perform the DB2 "commit" within 24 hours of storing the object. Failure to do this will ultimately result in loss of object data stored in the file system.

Another example is an application transaction to perform an object update, something OAM does not support. That is, an object can be retrieved using OAM, updated by the application, original version deleted by OAM, new version stored by OAM with the original name, then committed as a permanent change by the application when it is satisfied with the results. If the application is not satisfied with the results, it has the option of preserving the original object by backing out all of the changes made by OAM up to that point.