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.
Showing artifacts, examples and content with confirmed Node.js applicability. View All CAP
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().
A Node.js coverage assessment has not been written. View all flavors
No community artifact is confirmed here for Node.js.
A Node.js coverage assessment has not been written. View all flavors
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