## Transaction IDs

A `transaction_id` is a unique identifier that identifies the present or past transaction. A transaction is made up of one or more sub-transactions. A transaction has one `role` for the entire lifetime, but the transaction can different values of `status` as the transaction is processed.

For example, if the user "Installed OpenOffice" and the backend has to:

- update libxml2 as a dependency

- install java as dependency

- install openoffice-bin

- install openoffice-clipart

This is one single transaction with the role `install`, with 4 different sub-transactions. This allows the user to rollback transactions with selected backends, rather than select sub-transactions which may need complex conflict resolution.

The `transaction_id` must be of the format `/job_identifier_data` where the daemon controls all parameters. `job` is a monotonically updating number and is retained over reboots. `identifier` is random data used by the daemon to ensure jobs started in parallel cannot race, and also to make a malicious client program harder to write. `data` can be used for ref-counting in the backend or for any other purpose. It is designed to make the life of a backend writer a little bit easier. An example `transaction_id` would be `/45_dafeca_checkpoint32`