apache / apache/grails-core

@Transactional not applied to setter-like service method

Open
#14,539 3 comments 0 reactions 0 assignees View on GitHub
relates-to: documentation relates-to: gorm
Dominant language
Groovy
Stars
2.9k
Forks
975
Avg merge
1d 22h
Merged PRs (30d)
92

Description

### Task List

- [x] Steps to reproduce provided
- [x] Stacktrace (if present) provided
- [ ] Example that reproduces the problem uploaded to Github
- [x] Full description of the issue provided (see below)

### Steps to Reproduce

1. Create a grails service with `@Transactional` annotation
2. Create a method on that service called `setSystemConfiguration(List<...> configuration)` which should iterate the list an persist new instances of `SystemConfiguration`. No actual property like that exists on the service. Well it's a service, it does stuff, not hold stuff!
3. invoke that method.

### Expected Behaviour

`SystemConfiguration` objects are persisted to DB.

### Actual Behaviour

`setSystemConfiguration()` does seemingly nothing (when build with Hibernate 5.1.x) or throws an exception (with Hibernate 5.2.x) shown below.

```
Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress
at org.hibernate.internal.SessionImpl.checkTransactionNeeded(SessionImpl.java:3505)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1427)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1423)
at org.grails.orm.hibernate.AbstractHibernateGormInstanceApi.flushSession(AbstractHibernateGormInstanceApi.groovy:289)
at org.grails.orm.hibernate.AbstractHibernateGormInstanceApi$_performSave_closure3.doCall(AbstractHibernateGormInstanceApi.groovy:254)
at org.grails.orm.hibernate.GrailsHibernateTemplate.doExecute(GrailsHibernateTemplate.java:299)
at org.grails.orm.hibernate.GrailsHibernateTemplate.execute(GrailsHibernateTemplate.java:243)
at org.grails.orm.hibernate.GrailsHibernateTemplate.execute(GrailsHibernateTemplate.java:117)
at org.grails.orm.hibernate.AbstractHibernateGormInstanceApi.performSave(AbstractHibernateGormInstanceApi.groovy:251)
at org.grails.orm.hibernate.AbstractHibernateGormInstanceApi.save(AbstractHibernateGormInstanceApi.groovy:168)
at org.grails.datastore.gorm.GormEntity$Trait$Helper.save(GormEntity.groovy:151)
at xxx.xx.xxxx.ConfigurationService$_setSystemConfiguration_closure51$$ERBJdcoH.doCall(ConfigurationService.groovy:1005)
at xxx.xx.xxxx.ConfigurationService$$ERBJdcnT.setSystemConfiguration(ConfigurationService.groovy:1002)
at xxx.xx.xxxx.AdminController.setSystemConfiguration(AdminController.groovy:305)
... 42 common frames omitted
```

### Environment Information

- **Operating System**: WinX
- **GORM Version:** 6.1.11
- **Grails Version (if using Grails):** 3.3.9
- **JDK Version:** 1.8.0_192

### Description

From what I've gathered it's how class-level `@Transactional` transform is written - setters are skipped from adding transactional behaviour. The issue is that
* maybe a service method with setter-like name should not be skipped?
* this transform behavior _should definitely be documented_ but I failed to find it in either GORM or Grails docs.

**Workaround:** I can either rename the method, add `@Transactional` on the method directly or `SystemConfiguration.withTransaction { ... }` within the method. Either is cool, but I'd like to know about this kind of thing beforehand - upgrade docs did not mention this either, just that proxies are out, transforms are in.

Contributor guide

Open the contributing guide

Research direction

Start with the class-level @Transactional transform and the setter-like setSystemConfiguration method cited in ConfigurationService.groovy; the stack trace also points to AbstractHibernateGormInstanceApi.groovy. Compare the documented method-level annotation workaround and determine whether the intended outcome is changed behavior or documentation, with a regression test or documentation update defining what is done.

Written by the indexing model from the issue text.

Assessment

Tech stack
groovy
Domain
backend, database
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.