Spring’s JPA extension especially the declarative annotation makes the transaction management super convenient for developers, however, our RESTful application’s design need make the transaction boundary to as minimal as possible to avoid long running transaction and unnecessary transaction.
The major reason of avoid long running transaction and unnecessary transaction is from the connection pool, most of modern RESTful API application runs on DB or other transaction compliant resources use connection pool like Hikari to efficiently manage the DB or transaction compliant resources, we also use the connection pool to protect the RESTful system from overusing the hardware and software resources. Connection pool should recycle very quick so that any connection request can be served well, we should not let connection pool to be a performance bottleneck.
Here are the good transaction characters:
- Transaction should be processed very quick, averagely should be done within 200ms.
- Transaction should only be confined to DB or other transaction compliant resources.
Connection like other resource in our system should also be cherished, and used very economically, the connection pool should be configured to be nether overloaded or light-loaded. By doing this, beside turning the DB and connection pool we should also better design our RESTful API application to avoid long running transaction and unnecessary transaction.
Here is one of the design diagram that minimizes transaction boundary For RESTful API:
Some key things about the design above:
Dedicated DAO and DAO service
Each DAO should be simplified and only serve one type DB entity, it gives a good design scabbily and extensibility to our application. Each DAO needs a matched DAO service to handle more complicated DB logics. Transaction is declared and enforced on DAO service layer rather than DAO layer.
Combined DAO Service
Beside the dedicated DAO service which is matched to DAO, we should also define some combined DAO service, which combine multiple dedicated DAO services, it handles the across DB entity logics and transactions. The layer’s major roles are handling more complicated transaction logics and guaranteeing single responsibility principle on dedicated DAO services.
None DB Remote Web Service Broker
For other none DB related remote services like index, cache, clouding storage and other 3rd party web services, we define the dedicated broker services and isolate the logics from DB transactions.
RESTful presentation layer and business service
We define business oriented services to server the RESTful presentation layers, like Jersy resource classes. The business services are really dynamically defined with each particular presentation layer, it works as isolation layer to separate the detailed DB services and broker services from more easy changed presentation layer and business logics.
Based on above design layers and principles, the transaction and DB logics are confined greatly into a very limited transaction boundary. And we try our best to overuse of DB transactions and unnecessary transactions.
Any boundary broken uses should be prohibited, for instances, there should be no requests from broker services to DB services, and there should not DAO requests from business services without through the DAO services.