Grails Service Layer Architecture with Declarative Transaction Management

Requirements

Encapsulate business logic in a service, guarantee ACID transactions across multiple domain classes, and expose a thin API to controllers.

Smallest Suitable Design

Create a Grails service annotated with @Transactional (or set static transactional = true) that directly calls GORM methods on domain classes. No extra DTOs or service layers are needed for typical CRUD‑plus‑validation flows.

package com.example

import org.springframework.transaction.annotation.Transactional
import java.math.BigDecimal

class AccountService {

    @Transactional
    void transfer(Long fromId, Long toId, BigDecimal amount) {
        def from = Account.get(fromId)
        def to   = Account.get(toId)

        if (from == null || to == null) {
            throw new IllegalArgumentException("Account not found")
        }
        if (from.balance < amount) {
            throw new IllegalArgumentException("Insufficient funds")
        }

        from.balance -= amount
        to.balance   += amount

        from.save(flush:true)
        to.save(flush:true)
    }
}

The @Transactional annotation starts a Spring transaction before the method runs and commits it on normal completion; any unchecked exception triggers a rollback.

Trust and Data Boundaries

The service trusts that arguments have already been validated by command objects or GORM constraints. It never exposes the Hibernate Session or an open persistence context to the controller, keeping data access confined to the transaction boundary.

Operational Checks

To verify that a method runs inside a transaction, inject Spring's TransactionSynchronizationManager and check isActualTransactionActive():

import org.springframework.transaction.support.TransactionSynchronizationManager
import org.slf4j.Logger
import org.slf4j.LoggerFactory

class AccountService {
    private static final Logger log = LoggerFactory.getLogger(AccountService)

    @Transactional
    void transfer(...) {
        log.debug("Transaction active: {}", TransactionSynchronizationManager.isActualTransactionActive())
        // … method body …
    }
}

During development enable SQL logging to see a single BEGIN … COMMIT block:

# application.yml
grails:
  hibernate:
    sql-log: true

Run the application (e.g., ./gradlew bootRun) as a user with permission to execute Gradle and bind to the configured port. Observe the console; a successful call should show one BEGIN followed by one COMMIT, even if multiple save() statements occur.

Failure Modes

• Checked exceptions: By default Spring rolls back only for RuntimeException and Error. A checked exception will commit unless you add @Transactional(rollbackFor = Exception.class).
• I/O inside transaction: Performing a slow HTTP call or file write inside the transactional method holds the DB connection longer than needed, risking pool exhaustion under load.
• Self‑invocation: Calling another transactional method on the same service instance bypasses the Spring proxy, so the called method runs without transactional advice.

When the Design Must Change

If you need cross‑service sagas, long‑running business processes, or distributed transactions (e.g., updating a remote system alongside the DB), replace the simple @Transactional service with a coordination mechanism such as Grails async events, a message‑driven saga orchestrator, or an external transaction manager.