jakarta-eeweb-applicationstransactionsweb-container

How transaction used to handle during initial days of J2EE?

Although I learned Java almost a decade back, however mostly I have worked in C,C++, and core Java (not creating enterprise applications). Now, I have started to work in enterprise edition. I have some doubts on how things used to work in the initial days.

I am trying to understand how web-applications used to work. As per my understanding, the main technologies used in creating web-application are Servlets/JSP's (not considering higher abstraction on-top like Spring MVC , struts etc.) , deployed in a web-container (Apache Tomcat).

Now, using these, how it would take care of the transaction support? As per my understanding, a web-container doesn't have support for transaction. So does it mean initially the transaction support was by explicitly coding? (Transaction here I am referring to Database transactions / distributed transactions). If so, how robust this would have been?

Any information to understand this would be of great help.

Solution

  • Indeed, a barebones servletcontainer like Tomcat doesn't support any form of transaction management. You have basically three options:

    1. Manually manage transactions (can be done in JDBC, Hibernate as well as JPA).
    2. Or, use Spring for that.
    3. Or, replace Tomcat by a real Java EE server so you can use EJB/JTA. E.g. TomEE.

    This was not only true during "initial J2EE days", but is still very true these days. Only, J2EE's EJB 2.x was a terrible API in such way that Spring was then more often preferred. Since Java EE 5 (2006) EJB 3.x was much improved based on lessons learnt from Spring so there's not really a reason to supplant it with Spring if you have EJB readily available in a real Java EE server. Only ones who are stuck to Tomcat (e.g. customer or hosting restrictions) have usually no other choice than Spring to make transaction management a breeze.

    See also: