Ratpack a baza danych

Widzę, że Ratpack pojawia się tu na forum tylko gdzieś na marginesie, a przecież mamy tu promotora z DB na koszulce :)

Przejrzałem manual, przeszukałem na szybko net, ale nigdzie nie widzę informacji, jak na Ratpacku pracuje się z bazą danych. Nie ma puli połączeń, wstrzykiwania EntityManagera per request. To jak to się robi? Ręcznie, czyli implementować samemu? Po to zrobili EE i Springa, żeby się takimi rzeczami nie martwić...

Fajnie, że strona Ratpacka chodzi jak burza. Ale czy programista nie traci więcej czasu na pisanie? Podobno programiści są drodzy, a sprzęt jest tani.

Z tego co wiem to jest tylko serwer HTTP. Pewnie dlatego nic nie pisze tam o bazach danych.

Ratpack to biblioteka, która wykorzystuje nieblokujące API. JDBC w Javie jest blokujące. W dodatku zwykle w tego typu podejściu stosuje się bazy noSQL (np. Cassandra). Twórcy założyli, że pewnie ktoś sam ogarnie jak nieblokująco dostać się do bazy danych - Specjalny Driver / Pula osobnych wątków do połączeń.
Nie traktuj Ratpacka, jako framework do wszystkiego.

Tu masz ratpacka z bazą danych (zapisywanie rekordów)
https://github.com/javaFunAgain/ratpong/tree/h2
używam do tego JOOQ

https://github.com/javaFunAgain/ratpong/blob/h2/src/main/java/pl/setblack/pongi/scores/repo/ScoresRepositorySQL.java

Programista Ratpacka chodzi jak burza bo się nie musi rypać z magią, która czasem nie działa w piątki.
Ale Ratpack to dokładnie tylko i wyłącznie serwer HTTP.
Chcesz bazy danych SQL - to weź JOOQ. Możesz też wziąć Hibernate, ale Hibernate i wszystko około JPA to kaszanka.

Na devoxxie miałem prezentacje gdzie mówiłem o Ratpacku i przy okazji jak żenić SQL z Ratpackiem (nieblokująco... ).
Zresztą tu jest "istota" rozwiązania:
https://github.com/javaFunAgain/ratpong/blob/h2/src/main/java/pl/setblack/pongi/scores/repo/ScoresRepositoryProcessor.java

Executor przekłada pozwala nieblokująco wywoływać blokujący kod.
Sam Ratpack też zawiera podobny patttern.
https://ratpack.io/manual/current/async.html#performing_blocking_operations_eg_io

Jeśli chcesz pełne rozwiązanie (odpowiednik Springa lub JavaEE), gdzie wszystko Ci przygotowali (od HTTP do bazy danych) to jest coś takiego jak Lagom. Ja tam sobie wolę powybierać narzędzia, ale ten Lagom jest niczego sobie.

A co z pulą połączeń? Bo ja widzę, że Ty masz coś takiego w repository:

this.dbConnection = DriverManager.getConnection(url, userName, password);

Jeżeli dobrze śledzę kod, to tworzysz singleton service i singleton repository. Czyli wszystko bez puli połączeń, z jednym stałym podłączeniem do bazy danych. To jest rozumiem wersja demo, z jednowątkowym serwisem http.

Szczerze to pytałem o rozwiązanie produkcyjne. W rozwiązaniu produkcyjnym chcielibyśmy efektywnie wykorzystać procesor i serwer bazy danych, więc potrzebowalibyśmy wielowątkowej obsługi żądań http i wielowątkowego dostępu do bazy danych. Jak to zrobisz w Ratpacku?

1. Wielowątkowo bazę danych - to można dość trywialnie przerobić. Jak nie wiesz jak to pewnie jutro, albo pojutrze wrzucę (bo to istotny punkt - u mnie jest tam celowo jeden wątek, ale nie opisałem dlaczego (zapomniałem) ).

2. Natomiast co do wielowątkowego przetwarzania żądań HTTP... i efektywnego wykorzystania CPU.
   No musisz się zdecydować albo jedno albo drugie - czyli albo efektywnie albo wielowątkowo :-)

Podpowiedź : zwykle maksymalna sensowna liczbą wątków dla Ratpacka to liczba rdzeni procka.
(Tu ustawiasz
https://github.com/javaFunAgain/ratpong/blob/h2/src/main/java/pl/setblack/pongi/Server.java
.threads(4)

Wielowątkowo bazę danych - to można dość trywialnie przerobić. Jak nie wiesz jak to pewnie jutro, albo pojutrze wrzucę (bo to istotny punkt

Nie musisz tworzyć specjalnie dla mnie przykładu. Z Twoich postów wynikało, że stosujesz Ratpacka nagminnie w produkcji. Myślałem, że podasz tylko stos jaki stosujesz, w tym bazę danych, connection pool, itp. Teraz piszesz, że bazę danych wielowątkowo mam sobie sam robić... To ja już wiem, że się w to nie będę pakować.

.threads(4)

4 wątki i jedno Connection. Tak nie można, Connection nie jest thread-safe. Wiem, to tylko gałąź testowa, może zawierać śmieci.

Jedno Connection jest tam jak bajbardziej bezpieczne.
4 wątki sa na HTTP, ale tylko jeden wątek przetwarza operacje na DB (i to osobny od tych 4).

Generalnie bazy danych SQL (a bardziej nawet JDBC) słabo się z non blocking komponują (trzeba właśnie sztuczek tak jak w przykładzie używać).
Z Ratpackiem używa się MongoDB, CouchDB lub Cassandy i innych NoSQL generalnie (bo one mają asynchronizczne API).
Po to żeby nie było wielowątkowo - tylko jednowątkowo (no max 8).

NIe stosuję Ratpacka nagminnie w produkcji - dopiero w zeszłym roku udało mi się wepchnąć pierwszy serwis na Ratpacku i to mało ważny. No cóż pracuje w firmie ubzepieczeniowej, gdzie ustalona architektura to JavaEE (i w tym nagminnie pisze) - odbiegnięcie od standardu hoćby na krok to masakra (no ale jak widać się udaje). I nie mam bazy danych tam żadnej (DROP DB ) - albo są 4 jeśli inaczej spojrzeć - wszystkie dane obrabiam za pomocą różnych serwisów HTTP. (Które to HTTP na szczęście ma asynchroniczne API).