grpc services and @Transactional

[jorgheymans]

Hi,

It seems that spring's @transactional has no effect when used in a @GrpcService class. This is probably expected but nevertheless surprising. Integrating with spring's tx interceptor mechanics could make a worthy addition to this starter.

(and no i don't have a PR ready)

[jvmlet]

Have you tried to autowire the transactional bean into grpc service?

[jorgheymans]

If you mean wiring a transactional facade yes that's fine and that's how we do it now. But the fact that the grpcservice is a @component and it's methods look like the boundary methods of a traditional facade makes people want to put annotations on them. At least that's what happened in our team several times :-) Op wo 24 mei 2017 23:53 schreef Furer Alexander <notifications@github.com>:

…

Have you tried to autowire the transactional bean into grpc service? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL1AFCooffTnIhOLE9DWvqRtcA4wT9Tks5r9KbCgaJpZM4Nkwba> .

[jvmlet]

As I understand, the service method is being invoked by grpc framework directly and spring has no idea about it, that's why it can't create transaction around the invocation... I think custom grpc interceptor is the way to apply the @transactional logic....

[jvmlet]

Another thought : I was taught to always have clear separation of responsibility layers : transport, business and data access. Having @transactional being applied to transport method smells :-), at least for me. So, IMHO, you should continue to have facade to integrate with DB. What is your opinion?

[jorgheymans]

yes the grpc interceptor would suffice for the basic case, and custom per-method transactional semantics are more easily expressed using the separate transactional facade.

About the layer responsibility, It's the accepted way in java to pretend a clean architecture :-) . I tend to agree but for the simple case layering just bogs things down.

[pagrus7]

As a Spring framework user I confirm the natural expectation of @transactional (and other Spring goodness) working for grpc services, just like it works with e.g. spring MVC controllers and apache CXF services.

[jvmlet]

@pagrus7 , contributions are welcome.

[jorgheymans]

@pagrus7 how do you see this working with streaming rpc's ? The tx interceptor will only work well for the standard "simple RPC" case, once the client starts streaming you can no longer assume the same model applies. In some cases you might want to start a transaction server side per streaming call, whereas others would want the whole stream to be in the same transaction. You would probably need to implement a custom annotation or attribute on @GrpcService to express all these semantics. Don't think this is a small feat :-)

[pagrus7]

@jorgheymans I agree that in streaming context the declarative transactions on GRPC service are unlikely to be useful. Can't think of a valid use case. Unary RPC calls though can get the most benefit from transactions, and there are tons of use cases for them.

In short, I see @transactional working exactly like it would elsewhere: transaction opens before the method execution and commits right after. It is up to developer to decide on the meaningful use with respect to the RPC pattern they choose.

With all that said, based on a few experiments I suspect that transaction management (and other proxy-based goodness) does work already, assuming the right configuration is in place. Stay tuned as I'm writing the next comment.

[pagrus7]

Here is my example which combines @transactional and @GRpcService. It configures spring for proxying target class rather than using dynamic proxies. spring.aop.proxy-target-class=true does the trick; @EnableTransactionManagement(proxyTargetClass=true) would also work. Then, when GRPC binds a service and passes this as a service impl, interceptors are still preserved.

Looks like this proxy mode will be default in Spring Boot 2.x.

I encourage others to try switching from jdk proxies to cglib and validating if this indeed is a solution.

Update: noticed too late that AOP with class proxies is already under test

[jorgheymans]

@pagrus7 interesting thanks, so it seems that at most this 'feature' would need a small section in the documentation explaining things - great :)

[jvmlet]

It's interesting to see that interceptors are invoked before the actual proxied service call, run the
DemoAppTestAop test :

2017-10-10 13:28:25.870  INFO 8236 --- [    Test worker] o.lognet.springboot.grpc.DemoAppTestAop  : Started DemoAppTestAop in 3.083 seconds (JVM running for 4.273)
Greeter/SayHello
2017-10-10 13:28:26.224  INFO 8236 --- [ault-executor-0] o.l.springboot.grpc.demo.LogInterceptor  : Greeter/SayHello
2017-10-10 13:28:26.235  INFO 8236 --- [ault-executor-0] o.l.s.grpc.demo.AopServiceMonitor        : Hi from AOP. - before
2017-10-10 13:28:26.254  INFO 8236 --- [ault-executor-0] o.l.springboot.grpc.demo.GreeterService  : Returning Hello John
2017-10-10 13:28:26.255  INFO 8236 --- [ault-executor-0] o.l.s.grpc.demo.AopServiceMonitor        : Hi from AOP. - after

[pagrus7]

@jvmlet while I'm very new to GRPC, it looks like the interceptors are intended for augmenting a chain of listeners and handlers, rather than executing the cross-cutting logic in-place.

E.g. the following implementation of a logging interceptor

    @Override
    public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> call, Metadata headers,
                                                                 ServerCallHandler<ReqT, RespT> next) {

        ForwardingServerCall.SimpleForwardingServerCall loggingCall = new ForwardingServerCall.SimpleForwardingServerCall(call) {
            @Override
            public void sendMessage(Object message) {
                log.info("{} - responding with message - {} ", call.getMethodDescriptor().getFullMethodName(), message);
                super.sendMessage(message);
            }
        };

        ServerCall.Listener<ReqT> loggingListener = next.startCall(loggingCall, headers);
        SimpleForwardingServerCallListener loggingListenerWrapper = new SimpleForwardingServerCallListener(loggingListener) {
            @Override
            public void onMessage(Object message) {
                log.info("{} - received message - {} ", call.getMethodDescriptor().getFullMethodName(), message);
                super.onMessage(message);
            }

            @Override
            public void onComplete() {
                log.info("{} - call completed", call.getMethodDescriptor().getFullMethodName());
                super.onComplete();
            }
        };

        return loggingListenerWrapper;
    }

... produces the output which makes sense to me

2017-10-10 17:57:43.778  INFO 7924 --- [ault-executor-0] o.l.springboot.grpc.demo.LogInterceptor  : Greeter/SayHello - received message - name: "John"
 
2017-10-10 17:57:43.833  INFO 7924 --- [ault-executor-0] o.l.s.grpc.demo.AopServiceMonitor        : Hi from AOP. - before
2017-10-10 17:57:43.839  INFO 7924 --- [ault-executor-0] o.l.springboot.grpc.demo.LogInterceptor  : Greeter/SayHello - responding with message - message: "Hello John"
 
2017-10-10 17:57:43.843  INFO 7924 --- [ault-executor-0] o.l.springboot.grpc.demo.GreeterService  : Returning Hello John
2017-10-10 17:57:43.843  INFO 7924 --- [ault-executor-0] o.l.s.grpc.demo.AopServiceMonitor        : Hi from AOP. - after
2017-10-10 17:57:43.844  INFO 7924 --- [ault-executor-1] o.l.springboot.grpc.demo.LogInterceptor  : Greeter/SayHello - call completed

[jvmlet]

I would expect the LogInterceptor inerceptor to be executed between AopServiceMonitor's @Before and @After pointcuts, not vise versa...