Deciding where a unit of work begins and ends, and what travels with it: the database transaction that commits or rolls back around a request, the user, tenant and locale that every nested call inherits, and the work that must run outside the request in a transaction of its own. Distinct from concurrency controlConcurrency controlStopping two people who opened the same record from silently overwriting each other — detecting that the version you read is no longer the version you are saving over.SAP and community, unassessed, which is two writers on one record, and from async processingAsync processingDoing work outside the request that triggered it, with a guarantee that it eventually happens — deferred jobs, retries, and periodic work. Distinct from messaging, which is about telling other systems.SAP and community, narrow by design, which is work that survives the commit.
@sap/cds Starts, joins, commits and rolls back the database transaction around every service call, propagates user, tenant and locale through cds.context, demarcates a transaction by hand with cds.tx() and runs detached background work with cds.spawn().
com.sap.cds:cds-services-bom Opens a ChangeSet Context around the outermost event as the transactional boundary, with listeners, cancellation and Spring transaction integration, and a Request Context that carries user, tenant, locale and headers across services and into child threads.
Not covered: At the one database. A root transaction is one connection on one database; nothing spans two services' databases or a remote call, which is what the event queue's dispatch after commit exists for. SQLite allows no parallel transactions and deadlocks two that wait on each other; every asynchronous operation inside a spawned job must be awaited or the handling breaks; in Java a connection is reserved from the pool at the first persistence interaction and a Select starts no transaction unless enforced. Nothing outside the core is mapped here.
No community artifact is documented here.
An event handler no longer wraps its calls in cds.tx(req) to get context propagation and a managed transaction; the service runtime creates the transaction and propagates the context on its own. The old form still works and is deprecated. Dated from the first 5.0 release published on npm.
Handler code, and the samples it was copied from, that call cds.tx(req) before every read or write as if it were required.
capability:transaction-management