ORMIT™-Open Java's Automated Migration from Oracle Forms to Angular or React changes everything!

Concurrency in Oracle Forms

In traditional Oracle Forms applications, concurrency control relies heavily on the stateful connection between each user session and the Oracle database. Every session maintains a dedicated and persistent connection to the database, allowing Oracle Forms to handle:

• Record Locking: Automatic row-level locks as soon as a record is fetched for update.
• Session State Management: Transactional context persists for the duration of the user's session.
• Built-in Concurrency Handling: Oracle Forms detects conflicts if multiple users edit the same record and can warn users or block updates.

Concurrency in ORMIT™-OpenJava

After migrating with ORMIT™-OpenJava, the application architecture shifts to a stateless, service-based web application. The entire interaction between the frontend (React, Angular, or any other modern UI) and the backend is handled through RESTful API calls. These backend services connect to the database using JDBC, but the persistent session model is replaced by stateless request/response cycles.

This modernized architecture brings a fundamental change in concurrency handling:

• Each database operation (read, write, update) happens within the scope of a single REST request.
• There is no persistent connection per user. Instead, each request obtains a connection from a JDBC connection pool, performs the required action, commits or rolls back the transaction, and releases the connection.
• The database itself enforces physical concurrency rules (row-level locks, constraints, etc.), but Forms-level session awareness is no longer present.

Where is Concurrency Managed After Migration?

1. At the Database Level

Physical enforcement of concurrency — such as preventing two users from simultaneously inserting the same primary key or updating a record concurrently — is handled directly by the database. This is the same mechanism used by any modern web application connecting to a relational database.

2. At the Application Layer

To emulate business-level concurrency rules that Forms developers may have relied on (such as detecting if another user updated a record after it was loaded), the backend services can implement:

• Optimistic Locking: Each table includes a @version column. When a user edits a record, the PUT request includes the version. If the version has changed since the record was initially fetched, the backend detects the conflict and rejects the update.
• Pessimistic Locking: It ensures data integrity in high-concurrency environments.  When one transaction locks a row, other transactions must wait until the lock is released before they can read or modify the same data. 
• Business Rule Enforcement: Certain rules, such as "no two users can approve the same transaction" or "prevent concurrent submission of the same invoice," can be explicitly coded into the service layer. This is achieved by adding the @Trasactional annotation to guarantee ACID.
• Isolation Levels: It is possible to implement different types of transaction isolation levels such as READ_COMMITTED, REPEATABLE_READ and SERIALIZABLE.
• Custom Exceptions: The backend can return clear error messages to the frontend, such as "This record was modified by another user," ensuring users have a seamless experience.

Summary

Component	Oracle Forms	ORMIT-OpenJava
Connexion Type	Persistent (Stateful)	HikariCP Pool (stateless)
Session Duration	Long-lived	Per-transaction
Locking	Automatic (record-level)	Database + app logic (optional)
Concurrency Detection	Built into Forms runtime	Custom via optimistic locking (optional)
Physical Enforcement	Database	Database

 

 

 

 

 

 

 

Benefits of This Approach

• Fully compatible with cloud-native and containerized deployments.
• Supports horizontal scaling, as any application node can handle any request.
• Decouples frontend from backend, enabling better flexibility in UI technologies.
• Aligns with modern web development best practices, ensuring maintainability.

By combining database-level enforcement with application-level business rule checks, ORMIT™-OpenJava™ ensures the migrated application is reliable, scalable, and ready for the cloud, while still preserving critical concurrency controls that businesses rely on.

 

Interested in learning more about how ORMIT™-OpenJava handles other Oracle Forms capabilities? Contact RENAPS to schedule a technical deep dive.