JBoss EAPJakarta EEJava 21企業系統升級

JBoss EAP 05: MDBs, resource adapters, and IBM MQ delivery

··3 min read
Back to the JBoss EAP learning path

An HTTP caller waits for a response; an MDB is triggered by container-managed message delivery. If processing updates a database and then fails, rollback and redelivery may follow. Explaining the outcome requires delivery and transaction ownership, not just the body of onMessage.

Draw the complete delivery path

text
IBM MQ queue manager / queue
  → IBM MQ Jakarta resource adapter (RAR)
    → EAP EJB container → MDB.onMessage
      → business service → database

Transaction participation must be verified for each resource.

An MDB belongs to the EJB container; a Spring service belongs to Spring. Both support injection, but their lifecycles do not automatically merge. Identify how a called service is created and how transaction context crosses that boundary. Replacing an MDB with @JmsListener changes ownership and deserves a separate architecture decision.

Record three distinct version fields

Client libraries expose MQ APIs; the resource adapter integrates with the application server. IBM distributes wmq.jmsra.rar and wmq.jakarta.jmsra.rar for different API namespaces. Check the Jakarta adapter for this EAP 8.1 path. A specified client version of 9.4.5.1 does not establish the adapter or remote queue-manager version or support status.

Record adapter archive, connection factory, destination binding, physical queue, selector, concurrency, and transaction mode. Activation properties vary by adapter; examples for EAP’s integrated broker are not interchangeable with IBM MQ configuration. The kit contains a synthetic adapter declaration, not deployable MQ connectivity.

Method completion is part of a container transaction

For a container-managed MDB message listener, Jakarta Enterprise Beans permits REQUIRED or NOT_SUPPORTED transaction attributes. These are specification options; inspect annotations, descriptors, resources, and runtime to determine the effective choice and whether DB and MQ participate together.

Catching an exception, logging it, and returning without the required rollback signal may let the container treat processing as complete. Rollback can lead to another delivery of the same business event. Do not assume a single delivery. Verify redelivery thresholds, backout/error queues, and recovery against adapter, queue, and application configuration.

Exercise: fail after the database write

SurfaceRecord
DBOriginal state, changes, final transaction outcome
MQMessage identity, business key, delivery/error outcome
LogsCase correlation, exception, transaction outcome
RetryWhether the same event creates a duplicate side effect
Write expectations before gathering evidence in an isolated environment.

The answer is not always rollback. Derive expectations from the verified transaction model: one effective XA transaction and two independent commits can fail differently. Evaluate duplicates with the business key and established contract, not only one MQ message ID. Preserve the failure point and all evidence; this tutorial has not executed an enterprise MQ integration test.

Download the EAP offline kit: inventory, exercises, workbookNext: 06: Debugging and migration evidencePractice: lesson 10 transaction and redelivery model

Sources