The first transaction boundary pertains to capture/route processing. If the boundary is hit, a message has been read off the queue, been transformed into an event, and the event has been routed to a process. As part of this process, the event is written to the database. Once that write is successful, a commit is issued to the queue and the database and the transaction is closed. If the engine goes down before the transaction is closed, it is as if the message was never read from the queue. No commit will have been issued to either the queue manager or the database and the event will not exist. As long as the message is still on the queue and available to be read in again when the engine starts up, no data will be lost.
This means that you need to set the queuing system you are using to save the messages if the application goes down. As long as the queues are persistent and do not remove a message until they have received a commit, the message will not be lost. If there is a problem with the queuing system, the engine will suspend. What you do to recover in this instance will depend on the business processing being done by the engine. Once you have the queuing system running again and know where you stand with regard to messages on the queue, you can re-start the engine.
Once capture/route issues its commit, the event exists in the engine. It has been persisted to the database and can be retrieved in its entirety at any time. Included in the capture/route commit are all the routes for the event and the initial state of any process that was created because of the event. During capture/route processing routes for the event were determined and the EID-PID combinations were written to the route table. If the event required the creation of a new process, then the initial state has been written to the process table. At the end of the capture/route transaction, the event has been written to the event table, all its routes have been written to the route table, and any initial process states have been written to the process table. If the engine goes down before the transaction closes none of this information will be retained on the database and it will be as if it never happened. When the engine comes up, the message can be re-read off the queue and there is no danger of duplicate processing. If the engine goes down after the commit, the result of all the processing done to that point is saved and the engine can retrieve the information from the database.