Moved self database from session to request scope.

[criske]

PR for #442

A new db connection is established on each http request and closed after the request has completed.
This prevents "too many connections" exception from MySql to happen while too many users are logged in.

[zoeself]

@criske thank you for your Pull Request. I'll assign someone to review it soon.

[criske]

@amihaiemil this could be improved further if we pass a javax.sql.DataSource to MySql implemention and thus opening possibility to use connection pooling in the future.

no bounty needed for this PR :D

[zoeself]

@amihaiemil I couldn't find any assignee for this task. This is either because there are no contributors with role REV available or because the project does not have enough funds.

Please, make sure there is at least one available contributor with the required role and the project can afford to pay them.

[amihaiemil]

@criske Nu e mai bine sa fie session scoped? Imi amintesc ca intentionat am facut-o session scoped, ma gandeam ca e mai bine sa-si tina user-u conexiunea cat timp lucreaza in self-web (durata sesiunii), ca sa nu tot isi ceara fiecare conexiuni noi la fiecare request :-?

Oricum, cred ca e de ajuns sa pui RequestScoped pe SelfCoreComponent (si aia e Closeable si inchide fix instanta de DB).
Cum e facut acum, cred ca singurul avantaj e acea logare de request URL, dar n-as face o componenta noua doar pentru asta.

[criske]

@criske Nu e mai bine sa fie session scoped? Imi amintesc ca intentionat am facut-o session scoped, ma gandeam ca e mai bine sa-si tina user-u conexiunea cat timp lucreaza in self-web (durata sesiunii),

@amihaiemil la 150+ utilizatori logati in acelasi timp, mysql o sa crape, asta daca nu-i modifici max_connections.

ca sa nu tot isi ceara fiecare conexiuni noi la fiecare request :-?

De asta am amintit de connection pools.

Oricum, cred ca e de ajuns sa pui RequestScoped pe SelfCoreComponent (si aia e Closeable si inchide fix instanta de DB).
Cum e facut acum, cred ca singurul avantaj e acea logare de request URL, dar n-as face o componenta noua doar pentru asta.

SelfCoreComponent zic ca-i ok sa ramana asa cum e pe session scope.

[amihaiemil]

@criske jesus, numa' 150? Pai si daca sunt 150 de useri si e request scoped, si toti dau un refresh la pagina, nu tot acolo se ajunge?

Nu credeam ca trebuie sa ne batem capu cu connection pooling si chestii de genu asa repede...

[criske]

yep 151 https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections

[amihaiemil]

@criske clar intru sa modific pe server numaru ala, nu-i ok deloc. O sa merge-uiesc si PR-ul asta putin mai incolo, acum vreau sa fac un release cu ce avem saptamana asta (apropo, release 0.0.6 e deja facut, poti schimba la @since sa fie 0.0.7?) :D

[amihaiemil]

@criske apropo, ScropeProxyMode.INTERFACES ce face mai exact? : D

[criske]

@amihaiemil
Pt ca cele doua componente au durata de viata diferita (session > request), Spring are nevoie sa faca un proxy pt SelfDatabaseComponent .
ScropeProxyMode.INTERFACES instruieste Spring sa construiasca acel proxy la runtime dupa interfata Database (folosind dynamic proxy ).

Daca nu e setat pe ScropeProxyMode.INTERFACES default mergea pe ScopedProxyMode.TARGET_CLASS . Problema e ca modul asta incearca sa creeze la runtime o subclasa a SelfDatabaseComponent (folosind CGLIB ). Dar cum constructorul SelfCoreComponent asteapta un Database , Spring o sa gaseasca proxy-ul pt SelfDatabaseComponent si nu cel pt Database si o sa dea eroare.

[amihaiemil]

@criske ok, mersi de explicatie :D

[criske]

~~ Dar cum constructorul SelfCoreComponent asteapta un Database , Spring o sa gaseasca proxy-ul pt SelfDatabaseComponent si nu cel pt Database si o sa dea eroare.~~

@amihaiemil Scratch that, am reverificat si merge si fara ScropeProxyMode.INTERFACES. De fapt eroarea era daca incercam
injectez SelfDatabaseComponent in SelfCoreComponent si proxyul era pe interfaces. :D
Am sa scot modul ala si o las pe default.

[amihaiemil]

@criske stii cumva care ar fi impactul asupra vitezei daca facem schimbarea asta? Local si in Test poate nu se va vedea nu-stiu-ce pentru ca DB-ul e pe aceeasi masina.

Dar in Prod e o masina diferita si, in general, e acest trade-off: daca conexiunea e request-based, automat request-ul va dura mai mult :D

[criske]

@amihaiemil n-am testat, dar la momentul de fata, sa deschizi o connexiune la fiecare request e mult mai ineficient fata una per session.
Asa ca pe termen scurt, cred ca am putea sa ramanem pe session scoped.
Ma gandesc ca dpdv al scalabilitatii/performance progresia ar fi:

• conn per session
• conn per session + conn pool
• conn per request + conn pool

Pentru connection pool cel mai ok ar fi https://github.com/brettwooldridge/HikariCP .
Tot ce trebuie sa facem e sa modificam MySql sa accepte un DataSource si sa inlocuim DriverManager.getConnection() cu dataSource.getConnection()

Apropo, am gasit asta referitor la cum sa configurezi nr de max_connections in functie de ram in mysql: link

1 GB RAM	75
2 GB RAM	150
4 GB RAM	225
8 GB RAM	525
16 GB RAM	1,050
32 GB RAM	2,175
64 GB RAM	4,425

Also this: https://dba.stackexchange.com/questions/1229/how-do-you-calculate-mysql-max-connections-variable

max_connections = (Available RAM - Global Buffers) / Thread Buffers

[amihaiemil]

@criske mersi de info. Asa m-as gandi si eu, momentan sa lasam session scoped si daca da Domnu la mai multi user, scalam dupa aia cumva. Stii vorba aia: "I like to think how I can scale my application 10x before I even scaled it 2x" :))

Is socat de cat de putine conexiuni se recomanda. Eu imi inchipuiam cel putin cateva mii asa, din oficiu... :D

[amihaiemil]

@zoeself remove

[zoeself]

@zoeself remove

@amihaiemil ok, I've removed this task from scope. I'm not managing it anymore.