Czytając o frameworku Quarcus dowiedziałem się, że ma asynchroniczne "drivery" (opcję bez apostrofów zostawiam dla rozwiązań zestandaryzowanych) do Postgresa i MySQL (nareszcie!). Akurat bez MS-SQLa nie jest to dla mnie zbyt użyteczne.
Czy coś się dzieje w rynku javowym w tym względzie? Są jakieś prace? Są plany wydania asynchronicznego połączenia z bazami danych?
Dzieje się, ale powoli. Rozwiązaniem ma być Project Loom: https://openjdk.java.net/projects/loom/
Tutaj jest oświadczenie, które wygląda dość oficjalnie: https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html
Przeklejam:
On Wednesday, September 18, at Oracle CodeOne Oracle announced that Oracle will stop work on ADBA (Asynchronous Database Access). The API and the JDBC implementation were released with open source licenses so if anyone wants to continue work on it, you certainly can.
We stopped work on ADBA for two reasons: per the Java team the future for scalable Java code is fibers, not async and there was very little support within the Java community for ADBA. The announcement was made at a CodeONE session on scalable and asynchronous database access. The only person in attendance who was interested in ADBA was in fact happy to learn that we had stopped work on it. His interest was primarily concern about the work required to implement it if it became a standard. The Java team stated that ADBA would never be accepted as a Java standard as it was an async solution to a problem that would be addressed by fibers. Unless it became a standard ADBA would have very little impact, certainly not enough to justify the effort.
The Java team's position is that synchronous code is easier to write, test, debug, maintain, and understand than async code. The only reason to write async code is that threads are so expensive. Project Loom will add fibers, very lightweight threads, to Java. Fibers are so light weight that it is completely practical to spin up as many as you need. So just write first semester CS synchronous code and and execute it on a dedicated fiber. This is much easier than writing async code to do the same task. Synchronous code will use the same JDBC we all know and love. No need to learn a new API. Existing code can be made to work with few if any changes.
I'm not going to debate fibers vs async. That is not the purpose of this list and the decision has been made. I will say that a simple Loom test case created 2.5 million fibers in less than two minutes. I doubt you could create that many threads at all.
Oracle made the following product announcements at the CodeONE session.
Oracle 19c Oracle Database JDBC drivers are available on Maven Central.
Oracle 20c Oracle Database JDBC drivers are fiber-ready. Fibers impose some restrictions on user code. The Oracle Database JDBC drivers to be released in Oracle 20c have been tweaked to fully support fibers. As fibers are not yet part of the JDK, the 20c JDBC drivers do not use fibers. They will work properly with any user code that does use fibers though. So when Loom is integrated into the JDK, you can use the 20c or later Oracle Database JDBC drivers and get the full benefit.
If you desperately need async database access, Oracle 20c Oracle Database JDBC drivers include proprietary async extensions. We added a small number of async methods for those of you who need the scalability now. In the long term fibers are the answer but that's a couple of years away. If you must have a solution now then the 20c drivers provide minimal async support. These extensions are much, much simpler than ADBA and much less capable. We were aiming for 80/20; 80% of the benefit for 20% of the work. Probably more like 60/5.
You can see the slides here.
Douglas
Nie widzę związku między projektem Loom, a asynchronciznym (i nieblokującym) driverem do rdbms. Do Mongo, Cassandry czy Redisa już są takie drivery oparte na Nettym.
@AnyKtokolwiek to czego szukasz to https://github.com/r2dbc za którym stoi Pivotal
Charles_Ray napisał(a):
Nie widzę związku między projektem Loom, a asynchronciznym (i nieblokującym) driverem do rdbms.
No to radzę przeczytać cokolwiek o projekcie Loom, chociażby to co przytoczyłem w poście powyżej. W skrócie: jeżeli kod JDBC osadzisz w Fiberze, a nie bezpośrednio w wątku, to zamiast blokować wątek, będziesz blokował Fiber. Fibery są dużo tańsze niż wątki. Można mieć miliony Fiberów naraz, a to jest w tym przypadku jednoznaczne z milionami jednoczesnych zapytań do bazy. Zresztą powinien wystarczyć ten wycinek wypowiedzi, by rozwiać wątpliwości:
We stopped work on ADBA for two reasons: per the Java team the future for scalable Java code is fibers, not async and (...)
Dodatkowo jak zajrzysz do PDFa to zobaczysz, że bazka Oracle 20c ma asynchroniczne API oparte o Reactive Streams, ale jest ono obecne głównie dlatego, że włączenie Project Loom do standardowej wersji Javy może jeszcze potrwać kilka lat. Skopiowany tekst ze slajdu:
Oracle Database 20c JDBC Includes Async Extensions
- Oracle Database 20c JDBC drivers include a small number of proprietary extensions to support async database access
- The implementation uses NIO Selector so no threads block waiting on the database
- Minimal API. Not every use case supported
- No expectation that this wil ever be a Java standard. Fibers are the future for Java
To dlaczego np. dla Redisa dało się zrobić taki driver, a dla RDMBS nie? Czy problemem nie jest JDBC i tutaj Oracle podjął po prostu decyzję, że nie będzie szedł w async JDBC oparte o wątki, tylko o fibery? Dlaczego uważasz, że trzeba cokolwiek blokować?
Odnośnie Reactive Streams - to jest tylko standard, można implementować również na wątkach - zobacz np. na Reactora.
Z ciekawostek: w scali jest biblioteczka do postgresa, która jest zarówno pure functional jak i non blocking : https://tpolecat.github.io/skunk/index.html.
Swoją droga, polecam znaleźć prezentacje twórcy na YouTubie (nawet jak nie zna się scali) - mega ciekawa :)
Charles_Ray napisał(a):
To dlaczego np. dla Redisa dało się zrobić taki driver, a dla RDMBS nie?
Przecież Oracle już zrobił asynchroniczny driver do swojej bazy i API masz na slajdach w przytoczonym PDFie, więc skąd to pytanie? Ten driver jest tymczasowym rozwiązaniem zanim Project Loom wejdzie do głównej wersji Javy.
Czy problemem nie jest JDBC i tutaj Oracle podjął po prostu decyzję, że nie będzie szedł w async JDBC oparte o wątki, tylko o fibery? Dlaczego uważasz, że trzeba cokolwiek blokować?
Bo blokowanie jest łatwiejsze, a jednocześnie blokowanie fiberów jest tanie i to jest główny powód dla którego Oracle idzie w Fibery, a nie Future'y i tym podobne abstrakcje. Znowu zacytuję to co już zacytowałem (widać, że wyjątkowo nie masz ochoty czytać oficjalnych stanowisk Oracle'a):
The Java team's position is that synchronous code is easier to write, test, debug, maintain, and understand than async code. The only reason to write async code is that threads are so expensive. Project Loom will add fibers, very lightweight threads, to Java. Fibers are so light weight that it is completely practical to spin up as many as you need. So just write first semester CS synchronous code and and execute it on a dedicated fiber. This is much easier than writing async code to do the same task. Synchronous code will use the same JDBC we all know and love. No need to learn a new API. Existing code can be made to work with few if any changes.
Charles_Ray napisał(a):
To dlaczego np. dla Redisa dało się zrobić taki driver, a dla RDMBS nie? Czy problemem nie jest JDBC i tutaj Oracle podjął po prostu decyzję, że nie będzie szedł w async JDBC oparte o wątki, tylko o fibery? Dlaczego uważasz, że trzeba cokolwiek blokować?
IMHO ciężej jest o innowacyjne ruchy gdy coś jest mocno umieszczone w (oczekiwanych) standardach, świecie korporacyjnym itd.
Swiat NoSQL jest z zasady nie zestandaryzowany, ani nawet nie ma takich prób (każda baza jest zupełnie inna). Po drugie nurt NoSQL ukonstytuował się w czasach, gdy o async mówiło się powszechnie.
I jeszcze jedno.
Czy rozwiązania 'fiberowe' ładnie się dopasują do frameworków asyncowych (tu używam słowa w sensie ścisłym) jak RatPack, Quarcus i pewnie wiele innych?
BTW podrzucicie jakiś link o innych fajnych bibliotekach / frameworkach tej klasy?
@AnyKtokolwiek: prawdopodobnie tak. Fibery są niskopoziomowym API do wykorzystania w abstrakcjach wyższego poziomu.
Fibery z Project Loom mają ponadto potencjał rozwiązania (do pewnego stopnia?) problemu kolorowania funcji: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://news.ycombinator.com/item?id=8984648
Spora rozpiska porównująca fibery z Project Loom z innymi konstrukcjami (a)synchronicznymi jest tutaj: https://blog.softwaremill.com/will-project-loom-obliterate-java-futures-fb1a28508232
Materiału jest tyle, że nawet nie ma sensu przytaczać kawałków. Trzeba przeczytać całość :]
Jak ktoś lubi (tak jak ja) pierwszą porcję wiedzy przyjąć po polsku, Loom