Your use case:
- 'custom' Request #1 fails (no transaction yet)
- 'custom' Request #2 (creates nested 'add' request)
---- nested 'add' request (starts transaction and succeeds)
Alternative order:
- 'custom' Request #1 (creates nested 'add' request)
---- nested 'add' request (starts transaction and succeeds)
- 'custom' Request #2 fails (since transaction is already created it is rolled back)
So, in your case there's no reason for the transaction to be rolled back cause there were no failures since it was started, so it is committed. In alternative use case transaction is already in progress when we hit failed request #2, so it is rolled back. To avoid this you could make you custom requests part of transaction so that any failure in your setup would mean failure for the complete queue and would issue the rollback:
Code:
public DSResponse updateCustom(DSRequest request, HttpServletRequest servletRequest) throws Exception { [b][B]// Make request part of transaction[/b][/B] [b][B]request.setPartOfTransaction(true);[/b][/B] Long employeeId = (Long) request.getValues().get("EmployeeId"); if (employeeId.equals(4L) || employeeId.equals(182L)) return new DSResponse().setFailure("Editing of Charles Madigen and Tamara Kane forbidden"); DSRequest updateSalaryReq = new DSRequest(request.getDataSourceName(), DataSource.OP_UPDATE, request.getRPCManager()); updateSalaryReq.setFieldValue("Salary", 1000); updateSalaryReq.setAdvancedCriteria(new AdvancedCriteria(new SimpleCriterion("EmployeeId", DefaultOperators.Equals, employeeId))); DSResponse updateSalaryResp = updateSalaryReq.execute(); DSResponse myResponse = new DSResponse().setSuccess(); myResponse.addRelatedUpdate(updateSalaryResp); return myResponse; }
Leave a comment: