A repository maysupporttransactions.
Whether a particularimplementation supports transactions can be determined by queryingthe repository descriptor table with
.
A return value ofindicates support for transactions (seeRepository Descriptors).
A repository thatsupports transactions must adhere to the Java Transaction API (JTA)specification23.
The actual methodsused to control transaction boundaries are not defined by thisspecification. For example, there are nobegin,commitorrollback methods in JCR API. These methods are defined bythe JTA specification.
The JTA provides fortwo general approaches to transactions, container managedtransactions and user managed transactions. In the first case,container managed transactions, the transaction management is takencare of by the application server and it is entirely transparent tothe application using the API. The JTA interfacesandare the relevant ones in this context (though the client, asmentioned, will never have a need to use these).
In the second case,user managed transactions, the application using the API may chooseto control transaction boundaries from within the application. Inthis case the relevant interface is.This is the interface that provides the methods,,and so forth. Note that behind the scenes theandare still employed, but again, the client does not deal with these.
A content repositoryimplementation must support both of these approaches if it supportstransactions.
Throughout thisspecification we often mention the distinction betweentransientandpersistent levels. The persistent level refers to the(one or more) workspaces that make up the actual content storage ofthe repository. The transient level refers to in-memory storageassociated with a particularobject.
In these discussionswe usually assume that operations occur outside the context oftransactions; it is assumed thatand other workspace-altering methods immediately effect changes tothe persistent layer, causing those changes to be made visible toother sessions.
This is not thecase, however, once transactions are introduced. Within atransaction, changes made by(or other, workspace-direct, methods) are transactionalized and areonly persisted and published (made visible to other sessions), uponcommit of the transaction. A rollback will, conversely, revert theeffects of any saves or workspace-direct methods called within thetransaction.
Note, however, thatchanges made in the transient storage arenot recorded by atransaction. This means that a rollback will not revert changes madeto the transient storage of the.After a rollback theobject state will still contain any pending changes that werepresent before the rollback.
Because modificationsin the transient layer are not transactionalized, the possibilityexists for some implementations to allow ato be shared across transactions. This possibility arises because inJTA, anmay be successively associated with different global transactionsand in many implementations the natural mapping will be to make theimplement the.The following code snippet illustrates how anmay be shared across two global transactions:
Incases where thecorresponds to a(that is, probably most implementations), items that have beenobtained in the context ofwould still be valid when theis effectively associated with.In other words, all transactions working on the samewould share the transient items obtained through that.
In thoseimplementations that adopt a copy-on-read approach to transientstorage (see §10.11.9Seeing Changes Made by Other Sessions)this will mean that the a session is disassociated from a globaltransaction. This is however, outside the scope of thisspecification.