PartTree Delete queries cause nested Spanner transaction when using @Transactional

[guycall]

Describe the bug
I am not sure if this is expected behaviour, but Spanner delete operations raise exception within methods annotated with @Transactional.

Sample

@Transactional
public void handle(String ownerId, List<ItemEntity> newEntities) {

    itemRepository.deleteByOwnerId(ownerId);

    itemRepository.saveAll(newEntities); 
}

On entering this method a transaction is created: Creating new transaction with name [com.xxx.xxx.UpdateItem.handle]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

But executing deleteByOwnerId then triggers an exception:java.lang.IllegalStateException: There is already declarative transaction open.

I know Spanner does not allow nested transactions, and the docs state "The delete operation happens in a single transaction". But I wonder if this expected behaviour when using @transactional? Should the delete run inside the existing transaction?

Workaround
The workaround is to first read the entities to delete and then call itemRepository.deleteAll(entitiesToDelete)

NB: This is using version 1.2 of spring-cloud-gcp

[elefeint]

@guycall Thank you for describing the issue in detail. This should, in principle, work, and all repository methods should reuse the declared transaction.

@ddixit14 Can you try to reproduce this scenario (declarative @Transactional annotation on a service method calling a repository delete operation) in one of our samples? Declarative transaction management should work.

[toyopilgrim]

As @guycall stated,

itemRepository.deleteByOwnerId(ownerId);

This line is currently not able to work with @Transactional since deleteByOwnerId of spanner repository method will try to do ReadWriteTransaction with a context which has already begun at bean of SpannerTransactionManager(=@transactional). So nested transaction error is occurring then.

Meanwhile, delete/deleteAll just adds the mutation to a buffer not interrupting an existing context with @transactional.

So, straight workaround would be just to replace itemRepository.deleteByOwnerId(ownerId) with deleteAll/delete.

But both scenarios have to work, I believe.

[elefeint]

Thank you for the clarification!

[blakeli0]

Reproduced with the spring-cloud-gcp 4.2.0

Caused by: java.lang.IllegalStateException: There is already declarative transaction open. Spanner does not support nested transactions
	at com.google.cloud.spring.data.spanner.core.SpannerTemplate.lambda$performReadWriteTransaction$20(SpannerTemplate.java:440) ~[classes/:na]
	at com.google.cloud.spring.data.spanner.core.SpannerTemplate.doWithOrWithoutTransactionContext(SpannerTemplate.java:719) ~[classes/:na]
	at com.google.cloud.spring.data.spanner.core.SpannerTemplate.performReadWriteTransaction(SpannerTemplate.java:438) ~[classes/:na]
	at com.google.cloud.spring.data.spanner.repository.query.PartTreeSpannerQuery.executeRawResult(PartTreeSpannerQuery.java:71) ~[classes/:na]
	at com.google.cloud.spring.data.spanner.repository.query.AbstractSpannerQuery.execute(AbstractSpannerQuery.java:63) ~[classes/:na]
	at com.google.cloud.spring.data.spanner.repository.query.PartTreeSpannerQuery.execute(PartTreeSpannerQuery.java:35) ~[classes/:na]

[zhumin8]

fyi, the above 2 mentions are not related to this issue, and due to url mismatch in migrating the r2dbc module.