-
Story
-
Resolution: Done
-
Medium
-
None
-
None
-
Policy 04/11-17/11, Policy 18/11-01/12, Policy 02/12-15/12
Currently, the models Provider classes manage transactions. That approach has the advantage of hiding transactions from client classes. However, it has several shortcomings:
- Atomicity issues: the client does not have the ability to group DB changes into a single transaction. As a result, it's possible for some updates to the make it into the DB while others do not, leaving the DB in an erroneous state. It is also possible for different applications (e.g., API & PAP) to make inconsistent changes.
- Performance: performance is better if all of the DB updates are done in a single transaction rather than a transaction for each update.
- Complicated caching in clients: the clients must store all of the updates and then apply them at one time when completing a REST service. This complicates the clients significantly, because if the same record is updated more than once during a REST service, then the client must first check its own cache for a given record before checking the DB. This is something that JPA (and possibly some JDBC drivers) provides, but the client code cannot take advantage of it, because it is not in control of the transaction. The caching code is rather complicated and error prone.
Bottom line: the client is in the best position to know if a transaction is needed and to know where the transaction boundaries should be.
- is duplicated by
-
POLICY-1765 Reconsider exposing transactions via provider class
- Closed
- relates to
-
POLICY-2648 Make PAP component stateless
- Closed