Throughout this specification we often mention the distinction between transient and persistent levels. The persistent level refers to the (one or more) workspaces that make up the actual content storage of the repository. The transient level refers to in-memory storage associated with a particular Session object.
In these discussions we usually assume that operations occur outside the context of transactions; it is assumed that save and other workspace-altering methods immediately effect changes to the persistent layer, causing those changes to be made visible to other sessions.
This is not the case, however, once transactions are introduced. Within a transaction, changes made by save (or other, workspace-direct, methods) are transactionalized and are only persisted and published (made visible to other sessions), upon commit of the transaction. A rollback will, conversely, revert the effects of any saves or workspace-direct methods called within the transaction.
Note, however, that changes made in the transient storage are not recorded by a transaction. This means that a rollback will not revert changes made to the transient storage of the Session. After a rollback the Session object state will still contain any pending changes that were present before the rollback.