This chapter provides an overview of transaction processing and discusses how to work with transaction processing.
This chapter contains the following topics:
A transaction is a logical unit of work (comprising one or more SQL statements) performed on the database to complete a common task and maintain data consistency. Transaction statements are closely related and perform interdependent actions. Each statement performs part of the task, but all of them are required for the complete task.
Transaction processing ensures that related data is added to or deleted from the database simultaneously, thus preserving data integrity in your application. In transaction processing, data is not written to the database until a commit command is issued. When this happens, data is permanently written to the database.
For example, if a transaction comprises database operations to update two database tables, either all updates are made to both tables, or no updates are made to either table. This condition guarantees that the data remains in a consistent state and the integrity of the data is maintained.
You see a consistent view of the database during a transaction. You do not see changes from other users during a transaction.
Transaction processing ensures that transaction are:
Atomic
Either all database changes for an entire transaction are completed or none of the changes are completed.
Consistent
Database changes transform from one consistent database state to another.
Isolated
Transactions from concurrent applications do not interfere with each other. The updates from a transaction are not visible to other transactions that execute concurrently until the transaction commits.
Durable
Complete database operations are permanently written to the database.
The scope of a transaction is defined by the beginning and end of the transaction. The end of a transaction occurs when the transaction is committed or rolled back. If a transaction is started but not committed or rolled back, the system will roll back the transaction when user exists the system.
Transaction processing uses commits to control database operations. Commits are commands to the database. You can configure transactions to be automatically or manually committed. An auto commit transaction writes database changes permanently immediately when the changes occur. A manual commit transaction will buffer database changes when they occur, and only write database changes permanently when the transaction is committed.
A commit is an explicit command to the database to permanently store the results of operations performed by a statement. This event successfully ends a transaction.
A rollback is an explicit command to the database to cancel the results of operations performed by a statement. This event indicates that a transaction ended unsuccessfully.
Any failure to insert, update, or delete within a transaction boundary causes all record activity within that transaction to roll back. If no failures have occurred at the end of the transaction, a commit is done, and the records become available to other processes.
In the case of a catastrophic failure (such as due to network problems), the Database Management System (DBMS) performs an automatic rollback. Likewise, if the user clicks Cancel on a form, a rollback command can be issued through a system function.
A JD Edwards EnterpriseOne software transaction is a logical unit of work (comprised of one or more SQL statements) performed on any number of databases. A single-statement transaction consists of one statement; a multiple-statement transaction consists of more than one statement.
You can construct a transaction within an application to group multiple database operations. The application can then request the DBMS to buffer the database operations until the application executes a specific command to perform the updates requested within the transaction. Database operations that are not part of a transaction update the database immediately.
If an application has transaction processing turned on, other users cannot see the updated records until an update has been committed. Only processes within that transaction can access records in the transaction until the transaction is complete.
Transaction processing is supported to both interactive applications and batch applications (also called reports). Using Form Design Aid, you can enable transactions for JD Edwards EnterpriseOne forms. You can also design the database operations that are included in a transaction. Using Oracle's JD Edwards EnterpriseOne Report Design Aid, you can enable transactions and design transaction operations for batch applications. Not all applications enable transaction processing. Decide carefully whether transaction processing should be enabled.
If transaction processing is turned on for database operations for tables that reside in DB2 for IBM i, then those tables must be journaled. Journaling can decrease performance because of the additional processing required. Contact your DB2 administrator if you have problems with the process.
General messages and errors for transaction processing are written in jde.log, jdedebug.log or jas logs.
Data interdependence refers to the situation where data in multiple tables are dependent on each other. For example, a voucher has records in both the F0411 and the F0911 tables. Because data interdependence exists between these two tables, the transaction is incomplete when data is written in one table but not the other.
A transaction boundary encompasses all of the database operations that comprise a transaction. In interactive applications, a transaction boundary might include only the database operations on a single form. When a transaction includes data operations from another form, the transaction boundary must be extended to include that form.
The typical flow for a transaction is:
An application starts and calls the runtime engine.
The runtime engine initializes the transaction.
The runtime engine opens a view.
The runtime engine performs database operations.
The runtime engine commits database operations.
To include two connected forms in the same transaction boundary, you must activate transaction processing for the parent form and designate Include in parent on the interconnection to the second form. You do not need to activate transaction processing for the second form because your choice on the originating form overrides your choice on the called form.
This table outlines the relationship between two forms and the transaction boundaries that exist in each scenario. Transactions can be started in one form and extended to more forms through form interconnects and business function calls. In the example, the OK button on Form 1 invokes Form 2. You can change the transaction boundaries by specifying TP On or TP Off. The table explains what happens when you define your transaction boundary in various ways.
| Scenario | Forms | TP On | TP Off | "Include in Parent" flag On for Form Interconnect, BSFN, Table I/O | Comments |
|---|---|---|---|---|---|
| A | Form 1
Form 2 |
X
X |
All forms use Auto Commit. | ||
| B | Form 1
Form 2 |
X
X |
X | Because neither form uses Manual Commit, the Include in Parent flag on Form Interconnect Properties is ignored.
All forms use Auto Commit |
|
| C | Form 1
Form 2 |
X
O |
O
X |
Form 1 (parent) uses Manual Commit mode, and Form 2 (child) uses Auto Commit.
Because the Include in Parent flag is Off, the transaction boundary does not extend to include Form 2 (child) |
|
| D | Form 1
Form 2 |
X
O |
O
X |
X | Even though the transaction processing flag is Off for Form 2 (child), the Include in Parent flag is On.
The transaction boundary extends to include Form 2 (child) |
| E | Form 1
Form 2 |
O
X |
X
O |
Because the Include in Parent flag is Off, Form 1 (parent) and Form 2 (child) operate as independent entities.
Form 1 operates in Auto Commit mode and Form 2 operates in Manual Commit mode. |
|
| F | Form 1
Form 2 |
O
X |
X
O |
X | An atypical case. Because transaction processing is Off on Form 1 (parent), the transaction boundary does not extend to the child, even though the Include in Parent flag is On for Form 2 (child)
Form 2 (child) is in Manual Commit mode and the interconnect flag is ignored. |
| G | Form 1
Form 2 |
X
X |
Transaction processing is On for both forms.
Because in Include in Parent flag is Off, each form is a transaction boundary and a commit is issued for each. |
||
| H | Form 1
Form 2 |
X
X |
X | Transaction processing is On for both forms. However, because the Include in Parent flag is On, one transaction will incorporate both forms.
The transaction boundary encompasses both forms. Form 2 is a child of Form 1. |
An application or batch process establishes the primary transaction boundary. If an application calls a business function in Event Rules, the database operations in the business function are grouped within the boundaries of their parent application.
Master business functions should not define their own boundaries.
If your application calls several business functions, and you need to include the business functions in the transaction boundary, you must enable transaction processing for the application. Should a failure occur and you need to roll back database operations for the business function, you must designate Include in Transaction on the business function call.
Note:
When you use business functions within a transaction, you must be careful not to cause a deadlock. If two functions modify the same table, you might cause a deadlock if you include one function in the transaction but not the other. On the other hand, if a business function that selects records for information also updates or inserts data in other tables, you might want to split the business function.In a transaction-enabled application, if a server business function has modified a record, and a client business function outside the transaction attempts to access the record, the client function is locked out until the server business function has committed the data. Until the data is committed, the client application cannot access database changes performed by server-side business functions. If a server business function fails to commit or a user cancels a transaction on a server business function, the transaction for the business function rolls back.
Several transaction processing system functions are available. You might need to use these system functions for transaction processing.
For example, assume a scenario with two forms, Form A and Form B, with transaction processing enabled for Form A. Futhermore, assume that Form A calls Form B with the Include in Parent option on the Post OK Button is Clicked event. Because Form B inherits the transaction boundaries for Form A, if a user cancels an event on Form B, this occurs:
The entries for Form B are not written.
Control is returned to Form A.
The entries for Form A are written and committed.
In this scenario, you can prevent commitment of the entries for Form A by using the Rollback Transaction system function.
You can use these system functions to define transaction boundaries in a batch process:
Begin Transaction to define where the transaction begins.
Commit Transaction to commits a transaction.
Rollback Transaction to rollback a transaction.
For interactive applications, transaction processing is available for these form types:
Fix/Inspect
Header detail
Headerless detail
Power Edit
Editable Subforms
Wizard Form
Edit Portlet
Transaction processing is only available during OK processing for these events:
OK Button Clicked
OK Post Button Clicked
Add Record to DB – Before
Add Record to DB – After
Update Record to DB – Before
Update Record to DB – After
Add Grid Rec to DB – Before
Add Grid Rec to DB – After
All Grid Recs Added to DB
Update Grid Rec to DB – Before
Update Grid Rec to DB – After
All Grid Recs Updated to DB
Delete Grid Rec from DB – Before
Delete Grid Rec from DB – After
All Grid Recs Deleted from DB
Actions that occur outside of these events are not within the transaction boundary.
Note:
Transaction processing is also available for reports and batch applications. You can use the transaction processing system functions to define transaction boundary. You can also extend transaction boundaries through business function calls and table I/O calls.This section discusses how to:
Define transaction processing for a form.
Extend a transaction boundary.
| Form Name | FormID | Navigation | Usage |
|---|---|---|---|
| Form Design Aid | N/A | On Solution Explorer, type OMW in the Fast Path field. On Object Management Workbench, select an interactive application and click the Design Tools button. On the Interactive Applications Design form, select the Design Tools tab, and then click Start Form Design Aid button. | Create and modify interactive applications. |
To define transaction processing for a form, you must specify the Transaction option on Form Properties in Form Design. This requirement means that all data for the form is committed to the database at the same time.
If a transaction includes a single form, then this is the only action that is required because the form itself is the transaction boundary. However, if the transaction included data from another form, then you must extend the boundary to the applicable form through a form interconnection.
Note:
You can also extend transaction boundaries using business functions or table I/O.To define transaction processing for a form:
Double click the form for which you want to access Form Properties.
Click the Transaction Properties style option.
You can extend the transaction boundary from one form to another form by setting up a parent/child relationship between the forms. To extend the boundary enable the Transaction Processing flag through a form interconnection in Event Rules Design.
In Form Design, define form properties so that each form within the transaction boundary includes transaction processing.
If a parent form uses manual commit, the form to which you connect it must also use manual commit.
Select the parent form with which you are working.
From the Form menu, select Menu, Toolbar Exits.
Select the OK row and click the Event Rules button.
From Event Rules Design, select the Button Clicked event, and click the Form Interconnect button.
On Work with Applications, select the application that you want to use.
On Work with Forms, select the form that you want to include in the transaction boundary.
On Work with Versions, select the version of the application that you want to use.
On Form Interconnect, click the Include in Transaction Transaction Processing option, and click OK.
You can include a business function in a transaction boundary. If the parent form uses automatic commit, the business function to which you extend the transaction boundary also uses automatic commit. Any business function that is not marked as Include in Transaction uses auto-commit. Business functions that process asynchronously can also be included in a transaction.
Select the parent form with which you are working.
From the Form menu, select Menu, Toolbar Exits.
Select the OK row and click the Event Rules button.
From Event Rules Design, select the Button Clicked event, and click the Business Functions button.
From Business Function Search, select the business function that you want to include in the transaction boundary.
On Business Function, click the Include in Transaction Transaction Processing option.
Business Functions marked for both Asynchronous and Include in Transaction are included in the Transaction Boundary.
Transaction processing is available only for the Open Table operation in Table I/O. The opening of a table determines whether interaction with the table will be manual commit (part of a transaction) or automatic commit. Any Open Table operation not marked as Include in Transaction uses automatic commit.
Select the parent form with which you are working.
From the Form menu, select Menu, Toolbar Exits.
Select the OK row and click the Event Rules button.
From Event Rules Design, select the Button Clicked event, and click the Table I/O button.
On Insert Table I/O Operation, select the Open option under Advanced Operations, and then click Next.
On Data Source, click Advanced Options.
On Advanced Options, select the Include in Transaction option, and then click OK.
On Data Source, click Finish.
The Open operation appears in your event rules.
In addition to interactive transaction processing, JD Edwards EnterpriseOne software also provides transaction processing for reports and batch processes. To enable transaction processing for a batch process, click the Advanced tab for report properties and select Transaction Processing. Then use the Transaction Processing system functions to define the beginning and ending boundaries of the transactions. You can also extend your transaction boundaries to include business functions and table I/O.