Transactions Flashcards
What are the transaction management types that can be defined for an EJB?
Container
Bean
How do you specify a transaction management type using annotations?
@TransactionManagement is a class level annotation that accepts one argument of either:
TransactionManagementType.BEAN
TransactionManagementType.CONTAINER
What is the default transaction management type?
TransactionManagementType.CONTAINER
What are the transaction types that can be attached to a class or a method?
MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER
How are transaction types specified?
Using @TransactionAttribute either at the class level and or method level.
What is the default transaction type?
REQUIRED
Explain the MANDATORY transaction type.
MANDATORY: If this attribute is specified for a method, a transaction is expected to have already been started and be active when the method is called. If no transaction is active, an exception is thrown. This attribute is seldom used, but can be a development tool to catch transaction demarcation errors when it is expected that a transaction should already have been started.
Explain the REQUIRED transaction type.
REQUIRED: This attribute is the most common case in which a method is expected to be in a transaction. The container provides a guarantee that a transaction is active for the method. If one is already active, it is used; if one does not exist, a new transaction is created for the method execution.
Explain the REQUIRES_NEW transaction type.
REQUIRES_NEW: This attribute is used when the method always needs to be in its own transaction; that is, the method should be committed or rolled back independently of methods further up the call stack. It should be used with caution because it can lead to excessive transaction overhead.
Explain the SUPPORTS transaction type.
SUPPORTS: Methods marked with supports are not dependent on a transaction, but will tolerate running inside one if it exists. This is an indicator that no transactional resources are accessed in the method.
Explain the NOT_SUPPORTED transaction type.
NOT_SUPPORTED: A method marked to not support transactions will cause the container to suspend the current transaction if one is active when the method is called. It implies that the method does not perform transactional operations, but might fail in other ways that could undesirably affect the outcome of a transaction. This is not a commonly used attribute.
Explain the NEVER transaction type.
NEVER: A method marked to never support transactions will cause the container to throw an exception if a transaction is active when the method is called. This attribute is very seldom used, but can be a development tool to catch transaction demarcation errors when it is expected that transactions should already have been completed.