Apply transactional AST transformation to accessor methods in non-domain classes

[jpdev01]

Currently, methods whose names start with get* or set* are explicitly excluded
from transactional method decoration by AbstractMethodDecoratingTransformation.

While this behavior makes sense for stateful objects such as GORM domain classes
(where getters/setters may trigger lazy-loading, hydration, or expected exceptions),
it can lead to surprising behavior in stateless or prototype-scoped beans, especially
Services and background jobs.

In these cases, annotating a method like setAsDeleted() or getOrCreate() with
@Transactional silently results in the method not participating in a transaction,
which may cause data to be flushed and persisted even when an exception is thrown.

This behavior is non-obvious and has been reported as a gotcha by multiple users
(see #14539).

Proposed change

Introduce an opt-in mechanism to allow accessor-style methods (get* / set*)
to be wrapped in transactional logic when explicitly requested.

This preserves the existing default behavior (no transactional decoration for
accessors), while allowing advanced use cases—such as stateless services,
batch jobs, and background processes—to opt in safely.

---

Rationale

The original exclusion of getters and setters is reasonable for domain classes
and other stateful objects, where invoking accessors inside a transaction can
lead to unexpected side effects.

However, in stateless service-style beans, accessor-prefixed methods are often
used as semantic operations rather than property accessors, and excluding them
from transactional decoration can result in silent and hard-to-debug data
consistency issues.

Making this behavior opt-in avoids breaking existing assumptions while giving
developers an explicit and predictable escape hatch.

---

Related discussions

• @Transactional not applied to setter-like service method #14539
• https://grails.slack.com/archives/C07M0GTDE/p1765557083792879

[jpdev01]

Backwards compatibility:
A potential approach would be to make this behavior opt-in to avoid impacting existing applications.
This is intentionally left open for discussion.

[jdaugherty]

To address the intro/comments:

I'm not going to say no to this change if it's optional, but in general, I think this is an extremely bad smell in the code to use transactions on setters. Off the top of my head, here are some of the reasons I think this is bad:

• hydration / databinding will use setters. Starting and stopping transactions can cause data to save and data being saved during binding is likely a very bad idea.
• Also, what if the transaction = new transaction. The whole idea of a transaction is it's atomic, but as part of any databinding, multiple setters/getters will be called. This breaks the concept of a single action since each setter would cause a new transaction.
• setters are often used to set inputs to an object, if you were to do this on a service, it means that a transaction will wrap every bean wiring. That overhead is very likely not something you'd want.
• Groovy 4 focused on the bean spec & standardizing; I think there will be unintended consequences of this change for metaclass handling & places where the bean spec is used (like data binding / domains).
• This behavior will diverge from Spring's @Transactional and the differences are probably going to cause confusion.
• If a transaction changes data on a get, getters are no longer read only. I think that's an extremely dangerous precedent to set.
• Although this wouldn't necessarily apply to the domain, if using bean proxies (which spring does by default), I suspect there will be issues with getters/setters having transactions.

Will take a look at the code once people agree on a path forward. I do think this would have to go into 7.1 and not 7.0 too. @matrei @jamesfredley thoughts?

[jpdev01]

To address the intro/comments:

I'm not going to say no to this change if it's optional, but in general, I think this is an extremely bad smell in the code to use transactions on setters. Off the top of my head, here are some of the reasons I think this is bad:

• hydration / databinding will use setters. Starting and stopping transactions can cause data to save and data being saved during binding is likely a very bad idea.
• Also, what if the transaction = new transaction. The whole idea of a transaction is it's atomic, but as part of any databinding, multiple setters/getters will be called. This breaks the concept of a single action since each setter would cause a new transaction.
• setters are often used to set inputs to an object, if you were to do this on a service, it means that a transaction will wrap every bean wiring. That overhead is very likely not something you'd want.
• Groovy 4 focused on the bean spec & standardizing; I think there will be unintended consequences of this change for metaclass handling & places where the bean spec is used (like data binding / domains).
• This behavior will diverge from Spring's @Transactional and the differences are probably going to cause confusion.
• If a transaction changes data on a get, getters are no longer read only. I think that's an extremely dangerous precedent to set.
• Although this wouldn't necessarily apply to the domain, if using bean proxies (which spring does by default), I suspect there will be issues with getters/setters having transactions.

Will take a look at the code once people agree on a path forward. I do think this would have to go into 7.1 and not 7.0 too. @matrei @jamesfredley thoughts?

Currently we have some service methods in services named like setters (for example, setAsDone), but in practice they represent business commands, not simple property mutation.

My intention is not to make bean setters/getters transactional, nor to allow transactions to be started during data binding or object hydration. These methods are only used as explicit service-level operations, invoked from application use cases, and are not part of the bean/property specification.

To avoid exactly the issues you pointed out (data binding side effects, multiple transactions during object construction, confusion with the Spring transactional model, and unexpected interactions with the bean specification), I plan to adjust the method signatures and naming so that they clearly express application commands (for example, markAsDone, complete, etc.), while keeping setters strictly for simple state mutation.

This way, transactional boundaries remain at the service layer, but without giving these methods setter semantics or exposing them to any automatic binding or property access mechanisms.