Building Java EE apps with JTA transactions in NetBeans

Enterprise Java still drives significant backend work across Australia, from trading platforms maintained by the big four banks in Sydney and Melbourne to customs and biosecurity systems supporting the Port of Brisbane. Many of these systems rely on transactional integrity to keep GST calculations, BAS reporting, and audit trails consistent, which is why the Java Transaction API remains relevant.

NetBeans IDE brings together most of the pieces required to build such systems. It bundles project wizards for Enterprise JavaBeans, integrated JDBC management, a CPU profiler, and a deployment workflow aimed at GlassFish and Payara. For developers who split time between a Brisbane office and a Perth client site, having those tools in a single free IDE removes friction.

This walkthrough builds a small Java EE module, wires session beans to container-managed transactions, and validates the result against a local database, touching on profiling and JDBC configuration along the way.

Setting up the project in NetBeans IDE

Start with the Java EE bundle, which includes the GlassFish server adapter, EJB tooling, and JDBC drivers the rest of this article depends on. Installers are available for Windows, macOS, and Linux, supporting mixed teams such as Commonwealth Bank engineering hubs in Sydney and Adelaide.

After installation, point NetBeans at a JDK compatible with the chosen branch, typically JDK 11 or JDK 17 for recent builds. The New Project wizard offers a Java EE category with templates for EJB modules, enterprise applications combining EJB and WAR modules, and Maven archetypes. Teams building internal admin tools sometimes complement the wizard with a custom Swing palette to speed up interface prototyping alongside the transactional backend.

Configuring the project structure

A Java EE application in NetBeans is usually organised as an EAR containing an EJB jar for business logic and a WAR for the presentation tier. Maven is the default in modern releases because it simplifies dependency resolution when adding Jakarta EE APIs, although Ant-based projects remain supported.

Within the EJB module, NetBeans generates standard packages for session beans, message-driven beans, and helper classes. The build script registers each bean through ejb-jar.xml or annotations, depending on project style. Australian teams working with Defence or federal government suppliers often keep deployment descriptors explicit to satisfy security accreditation, making the annotated-plus-descriptor hybrid a common compromise.

Working with JTA and container-managed transactions

JTA defines how a transaction manager coordinates work across databases, message queues, and JMS topics. In a Java EE container, the default is container-managed transactions, declared through @Transactional or, in earlier code, @TransactionAttribute. The container begins, commits, or rolls back the transaction based on the bean's declared attribute, removing the need for manual begin and commit calls.

For most retail or logistics flows, the Required attribute is sufficient, ensuring a method runs within the caller's transaction or starts a new one if none exists. Scenarios that should always run independently, such as recording an audit event, benefit from RequiresNew. Where multiple databases are involved, splitting GST records between a transactional store and an ATO reporting schema, the container handles two-phase commit automatically, provided both resources enlist through the same transaction manager.

Implementing session beans with transaction attributes

A practical example is an order-processing bean for an Australian e-commerce operator. The stateless session bean exposes methods to place, cancel, and refund orders, each annotated with the appropriate transaction attribute. Place operations rely on Required so they participate in the calling workflow, while cancel operations use RequiresNew to guarantee the rollback is recorded even if the originating transaction later fails.

Message-driven beans, often wired to ActiveMQ Artemis, can also be transactional. When a shipment update arrives from a carrier API, the bean updates order status within a single transaction, ensuring database state and outgoing JMS messages stay consistent. NetBeans makes this visible by generating interceptor methods the debugger can step through, which helps chase down why a rollback did or did not occur.

Handling database connections with JDBC

Transaction behaviour only matters if the JDBC connection itself is properly enlisted. Inside the GlassFish or Payara server bundled with NetBeans, connections are defined as JDBC connection pools and exposed as JDBC resources that the application references by JNDI name. Once a pool is bound, every lookup inside an active JTA transaction is automatically enrolled.

For projects maintaining endpoints spread between an AEST-hosted production instance and a same-region disaster recovery node in Sydney, NetBeans also offers direct JDBC connection management inside the Services tab. This view lets developers run queries, inspect schema, and validate mappings without leaving the IDE.

Profiling CPU performance during transaction flows

Transactional code can hide expensive queries, especially when several beans coordinate across boundaries. NetBeans includes a built-in profiler that attaches to a running GlassFish instance and records CPU samples, memory allocations, and thread states while real requests are processed.

Attaching the profiler to a local deployment and exercising the order flow reveals which methods dominate response time. The same workflow surfaces accidental autocommit calls or missing indexes by exposing SQL latency alongside Java frames. Guidance on configuring sampling rates and filtering by package is covered in a dedicated CPU profiling walkthrough that complements this article.

Deploying and testing locally

Once the beans compile cleanly and the JDBC pool connects, NetBeans can deploy the EAR to a registered GlassFish instance with a single click. The Output window shows deployment progress, while the Server Log captures warnings related to transaction timeouts or stale resource references.

For repeatable regression checks, JUnit-style tests for session beans can run inside an embedded EJB container. This is useful for Australian teams that certify behaviour against compliance checklists before pushing to a UAT environment hosted by an external provider. Catching a misconfigured transaction attribute at this stage is far cheaper than discovering it after release.