JBoss EAP 04: JNDI, data sources, and transaction boundaries

The application cannot find OrdersDS, while an administrator sees that pool. They may be referring to different names: the management model identifies a pool, while the application looks up a JNDI binding. Establish the mapping before investigating connections and transactions.

Trace the name to a connection pool

Application lookup: java:/jdbc/OrdersDS
  → EAP data-source resource: OrdersDS
    → driver reference
      → connection pool → database

Names are illustrative, not target-system configuration.

DataSource exposes connection acquisition; the pool manages connection lifecycle. JNDI names resources rather than databases. A driver reference does not establish a JDBC artifact version: inspect the artifact and supported combination separately. DataSource remains javax.sql.DataSource on Java 21.

Let Boot look up an existing resource

# Illustrative application configuration for an EAP-hosted WAR.
spring.datasource.jndi-name=java:/jdbc/OrdersDS

This requests an existing JNDI DataSource. Custom beans, auto-configuration conditions, and deployment determine whether it takes effect. It neither creates the server resource nor proves correct transaction-manager wiring. If application code also creates a pool, inspect which bean is actually injected.

# Authorized standalone CLI; replace with a name discovered in the model.
/subsystem=datasources/data-source=OrdersDS:read-attribute(name=jndi-name)

Reading the attribute observes configuration. The separate test-connection-in-pool operation actively acquires or tests a database connection and is excluded from the kit’s observation list. Success still does not establish application SQL, schema access, isolation, or rollback behavior.

What JTA and XA each address

JTA supplies transaction-management APIs and coordination; XA is a protocol for participating resources. An XA data source declaration does not prove DB and MQ share one transaction. Manager selection, adapter capabilities, enlistment, recovery, and the executed path matter. Also verify which manager Spring selects and whether transactional interception applies.

Start with the business contract: must the database write and message publication commit atomically? If so, test commit, rollback, and recovery. If the existing system uses an outbox or compensation, validate that contract. Changing transaction architecture during migration makes differences harder to attribute.

Exercise: an omitted enabled attribute

The inventory reports enabled_declared: null for AuditXA. This means the file omits the attribute, not false or runtime availability. Design a failure after a DB write but before MQ completion. Derive expected database state, redelivery, and correlation evidence from the existing contract. Leave actual results pending until an environment runs the case.