β’
ν
μ€νΈ νκ²½
β¦
1λ² μλΉμ€ λ©μλμ 2λ² μλΉμ€ λ©μλ
β¦
1λ² μλΉμ€ λ©μλμμ 2λ² μλΉμ€ λ©μλλ₯Ό νΈμΆ
β¦
λ λ©μλ λͺ¨λ νΈλμμ
μ΄λ
Έν
μ΄μ
μ μ©
β’
2λ² μλΉμ€ λ©μλκ° REQUIRED μΌ λ
β¦
1λ² μλΉμ€ λ©μλλ§ readOnly μΌ λ
βͺ
1λ², 2λ² λ©μλ λͺ¨λ readOnly β μ νλ¨
β¦
2λ² μλΉμ€ λ©μλλ§ readOnly μΌ λ
βͺ
1λ², 2λ² λ©μλ λͺ¨λ readOnly X β readOnly=false λ μ νλ¨
β’
2λ² μλΉμ€ λ©μλκ° REQUIRES_NEW μΌ λ
β¦
2λ² μλΉμ€ λ©μλλ§ readOnly μΌ λ
βͺ
2λ² λ©μλλ§ readOnly
1λ²κ³Ό 2λ²μμ λ μ°λ λλ‘μ»¬μ΄ κ°λ€. κ·Όλ° μ λ€λ₯΄μ§?
The 'requires_new' propagation creates a new transaction for the second transaction, independent of the first transaction. Although both transactions may be executed within the same thread, they have separate transactional contexts.
When the second transaction starts with 'requires_new', it initializes its own thread-local transactional context, including the read-only flag. In this case, the read-only flag is explicitly set to true for the second transaction, overriding any previous settings from the first transaction.
Even though both transactions may be running in the same thread, the transaction management framework ensures that the thread-local transactional context is isolated and correctly reflects the desired behavior for each individual transaction. This allows for fine-grained control over transactional behavior, including the ability to have different read-only settings within a single thread.
resources.get()
1.
2.
3.