Ruslan Platonov - Transactions
•Download as ODP, PDF•
0 likes•569 views
The document discusses various transaction management patterns and anti-patterns, noting that the declarative transaction model using annotations or XML is preferred as it removes transaction logic from code. It describes common transaction patterns like open session in view and domain service owner that help define transaction boundaries and control, while also touching on other concepts like propagation and long running transactions. Developers are advised to use declarative patterns to clearly define transaction strategy and minimize bugs.
Report
Share
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (17)
Viewers also liked
Similar to Ruslan Platonov - Transactions
Similar to Ruslan Platonov - Transactions (20)
More from Dmitry Buzdin
More from Dmitry Buzdin (20)
Recently uploaded
Recently uploaded (20)
Ruslan Platonov - Transactions
- 1. Transaction Management Patterns Ruslan Platonov Lead Java Developer at C.T.Co
- 2. Definition of Transaction Transaction = Logical unit of work
- 3. Provides ACID Atomicity
- 4. Consistency
- 5. Isolation
- 6. Durability
- 7. Typical Issues Lack of knowledge in the area
- 8. Not clear understanding (knowledge) of transaction management strategy on application level
- 9. DB team should care about transactions
- 10. All these things results in anti patterns inside our projects
- 11. Ex 1: Auto-commit hibernate.connection.autocommit = true
- 13. Ex 2: Programmatic Control Connection connection = null ; Statement statement = null ; try { Class. forName ( "driverClass" ); connection = DriverManager.getConnection( "url" , "user" , "pass" ); connection.setAutoCommit( false ); statement = connection.createStatement(); // Execute queries statement.executeUpdate( "UPDATE Table1 SET Value = 1 WHERE Name = 'foo'" ); statement.executeUpdate( "UPDATE Table2 SET Value = 2 WHERE Name = 'bar'" ); connection.commit(); } catch (SQLException ex) { if ( null != connection) { connection.rollback(); } } finally { if ( null != statement) { statement.close(); } if ( null != connection) { connection.close(); } }
- 14. Ex 3: Incorrect Demarcation @ Repository public class UserRepository { @ Transactional public void save(User user) { ... } } @ Component public class UserService { @ Autowired private UserRepository repo ; public void disableUsers( List<User> usersList) { for (User user : usersList) { repo .save(user); } } }
- 15. Ex 4: Batch processing @ Component public class LongRunningJob { @ Autowired private RecordRepository repository ; @ Transactional public void updateRecords() { for ( int i = 1; i < 100000; i++) { Record rec = repository .getById(i); repository .updateTimeStamp(rec, new Date()); } } }
- 18. High load on DB
- 19. How can we improve our code?
- 20. Some Ideas Use declarative definition
- 21. Add transparency
- 22. Decouple from application logic, make flexible
- 26. Programmatic
- 27. Declarative
- 28. Local Transaction Model Transactions are handled by DB
- 29. Developer manage connections not transaction
- 30. Local Transaction Model Example
- 31. Local Transaction Model Considerations Not recommended
- 32. Suitable for simple cases
- 33. Plenty of room for errors
- 34. Cannot maintain ACID when coordinating multiple resources (DB, JMS)
- 35. Programmatic Transaction Model Developer manages transactions not connections
- 36. Developer is responsible for starting and terminating transactions
- 37. Programmatic Transaction Model Example
- 38. Programmatic Transaction Model with Decorator public class AccountServiceDecorator implements AccountService { private AccountService service ; public AccountServiceDecorator(AccountService service) {...} public boolean transfer(Amount amount, Account debetAcc, Account creditAcc { boolean transferred = false ; try { startTransaction(); transferred = service .transfer(amount, debetAcc, creditAcc); commit(); } catch (RuntimeException e) { rollback(); throw e; } return transferred; } }
- 39. Programmatic Transaction Model Considerations Not recommended
- 40. Typical scenarios Client-initiated transactions
- 42. Long running transactions (span multiple request) Manual handling of rollback (pay attention to exceptions)
- 43. Declarative Transaction Model The most recommended model
- 44. No Java code for transaction management
- 45. Developer only tells the container how to manage transactions
- 46. Declarative Transaction Model with ASPECT (1) public class AccountServiceImpl implements AccountService { @ Transactional public boolean transferAmount( final Amount amount, final Account debetAcc, final Account creditAcc) { ..... } }
- 47. Declarative Transaction Model with ASPECT (2) @ Aspect public class TransactionAspect { private TransactionService transactionService = new TransactionServiceNull(); @ Pointcut( "execution(@org.spring...Transactional * *(..))" ) public void transactionalMethod() {} public void setTransactionService( final TransactionService transactionService) { this . transactionService = transactionService; } .... to be continued ....
- 48. Declarative Transaction Model with ASPECT (3) ... continued ... @ Before( "transactionalMethod()" ) public void beforeTransactionalMethod(JoinPoint joinPoint) { transactionService.beginTransaction(); } @ AfterReturning( "transactionalMethod()" ) public void afterTransactionalMethod(JoinPoint joinPoint) { transactionService .commit(); } @ AfterThrowing(pointcut = "transactionalMethod()" , throwing = "e" ) public void afterThrowingFromTransactionalMethod(JoinPoint joinPoint, RuntimeException e) { transactionService.rollback(); } }
- 49. Declarative Transaction Model with Spring Annotations <context:component-scan base-package="com........" /> <tx:annotation-driven /> <bean id="txnMgr" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> @ Component public class UsersService { @ Transactional(propagation = Propagation.REQUIRED) public void modifyUser(User user) { ... } }
- 50. Declarative Transaction Model with Spring XML Configuration
- 51. Transaction Propagation Attribute Required – create new or reuse
- 52. Mandatory – reuse but never starts new
- 53. RequiresNew – always starts new
- 54. Supports – not require, but uses if present
- 55. NotSupported – suspends TX if present
- 56. Never – cannot be invoked with TX (throws exception)
- 58. Transaction Design Patterns Open Session in View
- 59. Client Owner
- 62. Open Session in View Pattern Transactions are demarcated on request level
- 63. Whole request is responsible for transaction management
- 64. Open Session in View Pattern Spring Example < filter > < filter-name > oemInViewFilter </ filter-name > < filter-class > org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter </ filter-class > < init-param > < param-name > entityManagerFactoryBeanName </ param-name > < param-value > reportsEntityManagerFactory </ param-value > </ init-param > </ filter > < filter-mapping > < filter-name > oemInViewFilter </ filter-name > < url-pattern > *.jsp </ url-pattern > </ filter-mapping >
- 65. Open Session in View Pattern Considerations Simple to implement and maintain
- 66. Single entry point for configuration
- 67. May lead to performance issues when mapped to any request
- 68. Not suitable for complex applications Has no control over transaction propagation
- 69. Doesn't support long transactions
- 70. Client Owner Pattern Client (presentation) layer is responsible for transaction management @ Component @ Scope(BeanDefinition.SCOPE_PROTOTYPE) public class MainScreenController { @ Transactional public void load() { // 1-N Calls to application } }
- 71. Client Owner Pattern Considerations More flexible control
- 72. Most suitable for fine-grained application services
- 73. Application and underlying layers should never take control over transactions
- 74. Most suitable for cases when application layer architecture can't be changed
- 75. Domain Service Owner Pattern Services layer is responsible for transaction handling @ Component @ Scope(BeanDefinition.SCOPE_PROTOTYPE) Public class MainScreenController { private MainScreenApplicationService service ; public void load() { service .load(); } } @ Component public class MainScreenApplicationService { @ Transactional public void load() { ... } }
- 76. Domain Service Owner Pattern Considerations Client always makes a single request to application layer
- 77. Services are course-grained (Facades)
- 78. Domain and persistence layers should never take control over transactions
- 79. Client doesn't contain any transaction logic
- 80. Server Delegate Owner Pattern A subtype of Command Pattern
- 81. External system / services facades own the transaction
- 82. Server Delegate Owner Pattern Example @ Component @ Transactional public class UpdateRateCommand { private CurrencyRateSystem crs ; private RateData data ; public UpdateRateCommand(RateData data) { this . data = data; } public void execute() { Currency currFrom = data .getFrom(); Currency currTo = data .getTo(); Rate rate = crs .rate(currFrom, currTo, new Date()); data .setRate(rate); } }
- 83. Server Delegate Owner Pattern Considerations Transactions are encapsulated
- 84. Transactions are not managed by presentation and services layers
- 85. There is even more to learn EJB Transaction management patterns and implementation
- 86. Java Transaction Service (JTS) and Java Transaction API (JTA)
- 88. Transaction management in JMS
- 90. …and more
- 91. Summary Try to use Declarative patterns only
- 92. Define transaction boundaries correctly
- 93. Use appropriate patterns to: Improve performance
- 94. Clearly define transaction management strategy
- 95. Make code easy to understand, implement and maintain
- 96. Minimize amount of bugs