To ensure security, both the application sending the logs and Graylog, which receives them, should be configured within a Private Subnet and located in the same VPC. This arrangement prevents the logs from being transmitted over the public internet.

If you specify @Async(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME) at the method level of your spring bean, it will automatically work as a Virtual Thread. I've added that to the article :)

Good point. JDK 21 wasn't out at the time of the original post, which is why there was a vestige of it in the example. As you say, the --enable-preview option is not needed in JDK 21. I've fixed the example as well. Thanks for the feedback :)

I fixed it. Thank yo so much.

This is a great article with a depth and insight rarely seen on the internet.

It also works well to specify @Transactional in a custom method of the Spring Data JPA interface, as in this example. This brings a lot of convenience to the developer, as they don't have to re-write each custom query with @Transactional in an outer contained class. In typical real-time business logic, most of the time the transaction propagation setting will use the default value of Propagation.REQUIRED, so you can also naturally carry over transactions created at higher Service levels.

Of course, it is most commonly used in concrete classes at the Service level :) In this example, I wanted to introduce you to the lowest level where you can use @Transactional in your project, so I showed you an example of specifying it in the @Repository interface. I make it a habit to specify @Repository and @Service, because that way I can cope with both transactions from real-time APIs with low execution time, and logic that has hours of execution time and intentionally doesn't use service-level transactions.

Thanks for the detailed and helpful information. :)

I'm glad to hear that my article was helpful to you. :)