Using journal objects

About this task
As a subclass of the Service class, the JDBCJournal class has an externalizer that allows it to define any journal object attributes in an definitions file (these attribute values are used when the journal object is instantiated), and it inherits all Service attributes, as, for instance, the name attribute that allows it to request a specific journal service instance in the hierarchy of contexts. To fulfill the J2EE compliance, the JDBCJournal object only accepts DataSource now.

After a journal service is instantiated by using the toolkit services externalizer and the context hierarchy, a name and a schema are assigned to the journal. The application must then set the entity name for that journal instance, request a database connection, and send the open() message to activate the current journal generation for that specific entity. After that, a current journal exists and is ready to be worked with.

When the application is done, the close() message can be sent to the journal. This operation sets the instance to inactive. This call is needed if at any time the same journal instance is requested to work with a different entity: for instance, if the entity is a user identification, and different users can work from the same workstation by changing the user and without closing the application. In that case, the journal instance must be closed and the entity name changed to the new value. The journal instance then needs to be opened again to continue working. You can query the current state of a journal object at any time by calling the isActive() method.

While a journal object is active, an application can add, retrieve, and update records.

The entity assigned to an active journal, the name of the journal service, the database connection, and the database connection properties (dataSourceName,connManager,schema) cannot be changed while the journal is active. Therefore, a close() message needs to be sent before any of these attributes can be changed.