Fix call to block() in CouchbaseCallbackTransactionManager.

[mikereiche]

Closes #1527.

• You have read the Spring Data contribution guidelines.
• There is a ticket in the bug tracker for the project in our JIRA.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[programmatix]

This isn't too great as a) it's not DRY or encapsulated - this functionality would really belong in TransactionMarkerOwner, and b) most importantly, it's removing a critical check. We won't know if we're inside a blocking transaction here, as we don't have the ThreadLocal check.

[mikereiche]

We won't know if we're inside a blocking transaction here, as we don't have the ThreadLocal check.
Both checks are there, however if the ctx is not due to the transaction, and there is indeed a blocking (ThreadLocal) transaction, we will miss it. Hence the request for a TransactionMarkerOwner api that does require a ctx and return a Mono to get the ThreadLocal core.

	boolean isExistingTransaction = ctx != null ? TransactionalSupport.checkForTransactionInThreadLocalStorage(ctx).isPresent() :
				TransactionalSupport.checkForTransactionInThreadLocalStorage().block().isPresent();

Right. So (a) requires the modification to TransactionMarkerOwner, and (b) needs what I've described in the other comment.

[programmatix]

What I meant on JCBC-1988 by "Refactor handlePropagation so we call TransactionalSupport.checkForTransactionInThreadLocalStorage() outside it and pass in the result."
is something like:

executeReactive():
		return TransactionalSupport.checkForTransactionInThreadLocalStorage().flatMap(isInTransaction -> {
		        boolean isInExistingTransaction = isInTransaction.isPresent();
			boolean createNewTransaction = handlePropagation(definition, isInExistingTransaction);
 
execute():
   boolean isInExistingTransaction = TransactionalSupport.checkForTransactionInThreadLocalStorage().block().isPresent();
   boolean createNewTransaction = handlePropagation(definition, isInExistingTransaction);

This preserves the full safety of the existing checkForTransactionInThreadLocalStorage() check (checking whether we are in either a reactive and blocking transaction), and just seems cleaner and simpler than the solution here.

[mikereiche]

In the execute() path, block() cannot be called as this may be in a NonBlocking thread.
TransactionMarkerOwner needs an api to get the Core out of ThreadLocal without calling block().

[programmatix]

The execute() path is inherently completely blocking (it is the blocking API) and hence can't be called from a NonBlocking thread. If they're trying to do a blocking transaction inside a reactive operator, then that is an application bug.

[programmatix]

Did we get to the bottom of how they ended up on the execute() path from a reactive @transactional? I read through 1527 and I took from it that our initial guess was that they didn't do @EnableTransactionManagement, but in fact they had.

[mikereiche]

The springframework TransactionInterceptor was being used instead of CouchbaseTranasctionInterceptor because the customer was configuring using yaml for configuration and not a class that extends that AbstractCouchbaseConfiguration like we had been doing. AbstractCouchbaseConfiguration has substitution of CouchbaseTransactionInterceptor.
I think you have a check for that in the code, but it hit the error on block() before the check.