5.3 Transactions Sample Application

In the Transactions sample application, the operation of registering for courses is executed within the scope of a transaction. The transaction model used in the Transactions sample application is a combination of the conversational model and the model in which a single client invocation invokes multiple individual operations on a database.

The Transactions sample application works in the following way:

1. Students submit a list of courses for which they want to be registered.
2. For each course in the list, the CORBA server application checks whether:
   • The course is in the database.
   • The student is already registered for a course.
   • The student exceeds the maximum number of credits the student can take.
3. One of the following occurs:
   • If the course meets all the criteria, the CORBA server application registers the student for the course.
   • If the course is not in the database or if the student is already registered for the course, the CORBA server application adds the course to a list of courses for which the student could not be registered. After processing all the registration requests, the CORBA server application returns the list of courses for which registration failed. The CORBA client application can then choose to either commit the transaction (thereby registering the student for the courses for which registration request succeeded) or to roll back the transaction (thus, not registering the student for any of the courses).
   • If the student exceeds the maximum number of credits the student can take, the CORBA server application returns a TooManyCredits user exception to the CORBA client application. The CORBA client application provides a brief message explaining that the request was rejected. The CORBA client application then rolls back the transaction.

The following figure illustrates how the Transactions sample application works.

Figure 5-2 Transactions Sample Application

The Transactions sample application shows two ways in which a transaction can be rolled back:

• Nonfatal. If the registration for a course fails because the course is not in the database, or because the student is already registered for the course, the CORBA server application returns the numbers of those courses to the CORBA client application. The decision to roll back the transaction lies with the user of the CORBA client application.
• Fatal. If the registration for a course fails because the student exceeds the maximum number of credits he or she can take, the CORBA server application generates a CORBA exception and returns it to the CORBA client application. The decision to roll back the transaction also lies with the CORBA client application.