Book Image

Jakarta EE Application Development - Second Edition

By : David R. Heffelfinger
Book Image

Jakarta EE Application Development - Second Edition

By: David R. Heffelfinger

Overview of this book

Jakarta EE stands as a robust standard with multiple implementations, presenting developers with a versatile toolkit for building enterprise applications. However, despite the advantages of enterprise application development, vendor lock-in remains a concern for many developers, limiting flexibility and interoperability across diverse environments. This Jakarta EE application development guide addresses the challenge of vendor lock-in by offering comprehensive coverage of the major Jakarta EE APIs and goes beyond the basics to help you develop applications deployable on any Jakarta EE compliant runtime. This book introduces you to JSON Processing and JSON Binding and shows you how the Model API and the Streaming API are used to process JSON data. You’ll then explore additional Jakarta EE APIs, such as WebSocket and Messaging, for loosely coupled, asynchronous communication and discover ways to secure applications with the Jakarta EE Security API. Finally, you'll learn about Jakarta RESTful web service development and techniques to develop cloud-ready microservices in Jakarta EE. By the end of this book, you'll have developed the skills to craft secure, scalable, and cloud-native microservices that solve modern enterprise challenges.
Table of Contents (18 chapters)
15
Chapter 15: Putting it All Together

Transactions in enterprise beans

As we mentioned earlier in this chapter, by default, all enterprise bean methods are automatically wrapped in a transaction. This default behavior is known as container-managed transactions, since transactions are managed by the Jakarta EE runtime. Application developers may also choose to manage transactions themselves. This can be accomplished by using bean-managed transactions. Both of these approaches are discussed in the following sections.

Container-managed transactions

Because enterprise bean methods are transactional by default, we run into an interesting dilemma when an enterprise bean method is invoked from client code that is already in a transaction. How should the Jakarta EE runtime behave? Should it suspend the client transaction, execute its method in a new transaction, and then resume the client transaction? Should it not create a new transaction and execute its method as part of the client transaction? Should it throw an exception...