Will java's virtual thread be useful for Grpc bidirectional stream application?

We have to create a microservice using spring boot + grpc.

We have to use Grpc's bidirectional streaming. So when client connects to the game, the connection is not disconnected until the client leaves the game. Our rpc will be like

service OurService {
  rpc Req(stream Request) returns (stream Event);
}

message Request {
  message Msg1 {}
  message Msg2 {}
  ...

  oneof request {
    Msg1 msg1 = 1;
    Msg2 msg2 = 2;
    ...
  }
}

...

In this situation, using java's virtual thread created loom project is still useful?

I don't know which is better virtual thread + JPA VS spring webflux + r2dbc or other? We expect there's a lot of traffic and there's many communication with the database (mysql or amazon's aurora)

The main impact of virtual threads to you would be "do virtual threads allow me to organize my code in a way that is easier to write and maintain." For gRPC Java in particular with a streaming RPC, the only stub is asynchronous so there's few opportunities for using virtual threads.

There is ongoing work for adding a blocking client stub for streaming RPCs. With that you could choose to use the blocking API on the client-side. But it sounds like your clients have few concurrent RPCs, so there's little difference between real threads and virtual threads. The larger value would be using virtual threads on the server-side, but you would have to wait for gRPC to provide a blocking API on server-side.