## 8 Conclusions  
To emphasize the performance differences after introducing the warm-up, we will briefly review the conclusions of the experiments that were not using it. For the work without JMH, A great overall performance is offered by MySQL. It has incredibly good execution times, despite having a slower performance than PostgreSQL for creating, reading, and updating entries, but it saves a lot of time on the delete operation. The experiments were designed to provide multi-criteria analysis, using different RDBMSs together with different ORM frameworks. This way, software engineers may decide based on the specificity of their projects and on the operations that they forecast to be intensive for their circumstances. Performance is similar for Hibernate and Java Persistence API, while Spring Data JPA brings a lot of overhead with it, but it also offers an easier solution regarding the code dimension to access and modify data. After the warm-up phase, the only CRUD operation that had a visible and constant improvement was the READ one. For the rest of the operations, the improvements are \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Operation**} & \multicolumn{4}{c}{**Relational Database Management System**} \\ \cline{2-5}  & **MySQL** & **Oracle** & **SQLServer** & **PostgreSQL** \\ \hline Create & 43,371 & 68,977 & 42,253 & 31,839 \\ \hline Read & 314 & 976 & 261 & 271 \\ \hline Update & 33,955 & 29,537 & 27,668 & 18,924 \\ \hline Delete & 42,988 & 113,404 & 381,440 & 326,854 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Execution times in milliseconds, 50k entries, after transaction management refactor. \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Operation**} & \multicolumn{4}{c}{**Relational Database Management System**} \\ \cline{2-5}  & **MySQL** & **Oracle** & **SQLServer** & **PostgreSQL** \\ \hline Create & 40,688 & 65,406 & 39,076 & 29,389 \\ \hline Read & 278 & 878 & 218 & 202 \\ \hline Update & 31,887 & 28,601 & 25,955 & 17,682 \\ \hline Delete & 40,001 & 112,778 & 359,862 & 314,171 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Execution times in milliseconds for 50k entries with Hibernate. generally noticed on a small number of entries (less than 20k or 50k). What may be surprising is that sometimes, usually for a large number of entries (500k), the warm-up phase is useless, as the execution times for the second iteration are even bigger. After researching what could make Spring Data JPA's transaction management act so slow, the conclusion was that it does not have just an EntityManager, but it has a SharedEntityManagerCreator which creates more objects of type EntityManager to avoid possible thread safety issues. The classic EntityManager generated using EntityManagerFactory used in the JPA implementation does not offer thread safety, but in the proposed experiment this is not necessary. Using it makes Spring Data JPA faster in its interaction with the relational database management system. Switching the transaction management turns Spring Data JPA into a similar solution in terms of performance like JPA or Hibernate. This means that the starvation situations mentioned by the YourKit profiler are happening somewhere inside the transaction mechanism proposed by Spring Data JPA. Designing enterprise applications nowadays is a real challenge and involves a lot of high-level skills and experience. Alongside designing [43] and assessing the architecture [44], selecting and applying the software development methodology [45], and testing the functionality [39], performance plays an essential role in modern software. Selecting the best database and ORM that suits a project is a matter of finding a trade-off between the execution speed on one side, and development speed on the other side, and extensive experimental results strongly support such a decision.