Stop calling the explicit Commit method in your Pega Queue Processor activities

If you plan to use a queue processor for some processing, such as updating the properties of any work item, creating a new work item, or updating a few records in a specific data type, developers mostly call the Commit method in the queue processor activity.

Commit activity method is used to save and commit the database operations performed previously and not committed already. However, using the commit method in Queue processor activity can adversely affect the outcome of the queue processor.

Consider a scenario involving a queue processor used for Airline Seat Reservation, where a "Race Condition" might occur. Completing an Airline Reservation requires two transactions, as detailed below.

• Operation A: Insert a record into the Booking table for a specific passenger.

• Operation B: Update the Seats table to change the status of Seat 12A from "Available" to "Occupied."

• Failure Risk: If the seat is marked occupied but no booking record exists, the airline loses revenue on a "ghost" seat. If the booking is recorded but the seat remains available, two people might be sold the same seat (Double Booking).

If both operations are successful, the entire transaction is marked as successful. However, if any operation fails, the entire transaction must be rolled back.

In database management and system design, this scenario is referred to as an Atomic Transaction (the "A" in ACID). It ensures that a series of operations are treated as a single unit of work: either all operations succeed, or none do.

Now let's go back to Queue processor activity which is performing these DB operations. If you explicitly call commit method and if any one of the commit fails, then we will end up with data inconsistency like described above.

To address this type of issue and manage Atomic Transactions, refrain from explicitly invoking the commit method within the Queue processor activity or any activities initiated by it. The Queue processor is specifically designed to manage Atomic Transactions, committing only when both operations are successful. If any operation fails, all actions will be rolled back.

In the described use case, the Queue processor successfully processes Operation A, which inserts a record into the booking table. However, if it fails to insert a record into the seat table, the Queue processor will roll back Operation A to prevent any data inconsistencies. This is feasible because the Queue processor treats the entire transaction as a single unit and commits only when all operations succeed or fail. Explicitly calling a commit disrupts this process, as it impairs the Queue processor's ability to retry failed transactions. If one operation is committed to the database while another fails, a retry by the Queue processor would result in the successful operation being executed twice, leading to data issues.

Therefore, avoid invoking the commit method from the Queue processor activity or any other activity that is triggered by it. The Queue processor independently manages database transactions.