spring - real life scenarios for Transaction propagation -

there various transaction propagation like

required - case dml operation.

supports - case querying database.

mandatory - ? requires_new - ? not_supported - ? never - ? nested - ? 

what real life scenarios use these transaction propagation? why these perfect fit situation?

there various usages , there no simple answer i'll try explainatory

• mandatory (expecting transaction): typically used when expect "higher-context" layer started transaction , want continue in it. example if want 1 transaction whole operation http request response. start transaction on jax-rs resource level , lower layers (services) require transaction run within (otherwise exception thrown).
• requires_new (always create new transaction): creates new transaction , suspends current 1 if exists. above example, level set on jax-rs resource example. or if flow somehow changes , want split logic multiple transactions (so code have mutliple logic operations should separated).
• required (continue in transaction or create if needed): kind of mix between mandatory , requires_new. in mandatory expect transaction exists, level hope exists , if not, create it. typically used in dao-like services (from experience), depends on logic of app.
• supports (caller decides whether not/run in transaction): used if want use same context caller (higher context), if caller running in transaction, run in too. if didn't, non-transactional. may used in dao-like services if want higher context decide.
• nested (sub-transaction): must admit didn't use 1 in real code create real sub-transaction works kind of checkpoint. runs in context of "parent" transaction if fails returns checkpoint (start of nested transaction). may useful when require kind of logic in application, example if want insert large number of items database, commiting valid ones , keeping track of invalid ones (so can catch exception when nested transaction fails can still commit whole transaction valid ones)
• never (expecting there no transaction): case when want sure no transaction exists @ all. if code runs in transaction reaches code, exception thrown. typically cases opposite mandartory. e.g. when know no transaction should affected code - because transaction should not exist.
• not_supported (continue non-transactionally): weaker never, want code run non-transactionally. if somehow enter code context transaction is, suspend transaction , continue non-transactionally.

from experience, want 1 business action atomic. want 1 transaction per request/... example simple rest call via http db operations in 1 http-like transaction. typical usage requires_new on top level (jax-rs resource) , mandatory on lower level services injected resource (or lower).

this may useful you. describes how code behave given propagation (caller->method)

• required: none->t1, t1->t1
• requires_new: none->t1, t1->t2
• mandatory: none->exception, t1->t1
• not_supported: none->none, t1->none
• supports: none->none, t1->t1
• never: none->none, t1->exception