JetNet/Oracle Tuxedo Guide

Chapter 7. Transaction Model for JetNet

On the client side, service requests are made to access the database by user input on a client screen. These requests can be directed to the transaction manager, which through the middleware transaction model, decides what services need to be called to satisfy the requests.

In two-tier applications, the transaction model generates transaction manager events; in three-tier JetNet applications, the transaction model generates service requests.

jetrb1 is the transaction model provided for three-tier JetNet applications. When a client uses the transaction manager, jetrb1 determines which service request to make to satisfy the transaction manager command. jetrb1 provides processing for the following transaction manager events: TM_SELECT, TM_VIEW, TM_DELETE, TM_DELETE_EXEC, TM_INSERT, TM_POST_SAVE, and TM_VAL_LINK.

The service properties of the table views and link widgets on the client screen are checked to determine which services to call. If no services are specified in the properties, the default, built-in services are called.

Built-in Services

The built-in services are used on:

The services perform transaction manager operations for the client by executing sm_tm_command. The operations handled by the built-in services are: SAVE, SELECT, VIEW, INSERT, DELETE, and VALIDATE LINK. These services are advertised by a conversion server. For more information on the conversion server, progserv, refer to page 2-2.The built-in services cannot be modified.

Modifying the Model

The jetrb1 transaction model should prove sufficient for your database processing needs, but should you need to modify the behavior you can do so. If the behavior that requires modifying is application-wide, you can modify the source code of the model directly. Otherwise, you can provide hook functions on a screen-by-screen basis for particular transaction manager events. Write a hook function and assign it to the Database Function property of the screen's table view.

You might want to modify the behavior of jetrb1 to augment the service call functionality, perhaps to add arguments to the service call, to make an additional service call, or to replace the service call with different one.

For example, if a SELECT operation requires non-screen variables, this would require changing the processing of the TM_SELECT event either in jetrb1 or in a hook function written to intercept this event. This could be necessary if a multi-screen transaction requires additional variables, perhaps from the LDB or from non-screen variables.

jetrb1 is a C source module located at $SMBASE/samples/jetrb1.c.

To modify it, first make a copy, then do your edits and rebuild your executables. You will need to add the object module in the makefile in the place reserved for your source modules.

Service Limitations

The built-in services are only called for full commands. If a screen implements partial commands, you will have to either write a service to implement the partial command (and specify the service in the appropriate service property) or modify jetrb1. For example, if a screen has master and detail sections, and both use grids, the detail portion of the screen will not update when the focus in the master section changes to another record.

If a service property is set on a non-root table view, then all table views must have their service properties set. If no service properties on the root table view are set but a service property is set on a subordinate table view on the screen, no action is taken. The built-in services will not be called, and the service in the property that is set will not be called.

Server Processing

On the server end, the middleware API receives service requests. The service requests are sent to the transaction manager, which, using the database transaction model, passes the requests to the SQL generator where the SQL is constructed. From there, the database driver (for your database) sends the appropriate instructions to the database. Responses back from the database travel the same path in reverse.

Transactional Control

Database transactions are database operations that are completed or canceled as a unit. For example, a change to a record in a database can comprise INSERT, UPDATE, and DELETE operations. These operations are executed as part of a transaction, so that if any one fails for any reason, all three are rolled back and the information in the database is restored to its former state. The operations are only completed and committed to permanent storage in the database when all three have succeeded.

Middleware systems do not provide transactional control; they rely on the transaction capabilities of the database as invoked by the application server. In a three-tier application, the transaction model on the application server determines how database transactional processing should be invoked. The Oracle Tuxedo middleware adapter supports XA transactions. For further information on transaction management, refer to page 8-3