Avatar billede Droa Seniormester
16. august 2017 - 12:57 Der er 5 kommentarer og
1 løsning

mange tråde med samme database tilgang

Hej eksperter.
Jeg sidder og er ved og udvikle noget asynkron behandling af data, der derefter skal gammes i en database.

dataen kan både komme "udefra" men os fra selve databasen, hvor den derefter skal behandles i en tråd, og ligges tilbage i databasen igen.

det handler om ca 100 tabeller, i 1 database, med tæt på en million main entities, der alle binder til tabeller.

jeg har nogen tabeller som jeg søger i engang imellem, om der er "tasks" der skal laves, hvis der er een eller flere "tasks" vi tråde blive sat igang med og udføre jobs, og sætte status fra "notstartet" til "startet", og når tråeden er færdig, vil den sætte status til "done".


min ide var og lave en enkelt tråd("tasksupervisor") der søger i "task" -tabellerne, "tasksupervisor" danner derefter en eller flere tasks i en taskgroup, med hver enkelte task("task1, task2,...task100"), hvor hvis der er for mange tasks igang på samme tid, vil den danne en kø-buffer, som den vil begynde og tage fra, efter at tasks bliver færdige.

nu er det så sådan at hver enkelte task også skal kunne skrive tilbage til databasen, og jeg er lidt i tvivl om hvordan man skal gøre dette korrekt, skal man bare gøre det i hver eneklte task, eller skal man lave en form for return-objekt, der så har informationer til og lade "tasksupervisor" skrive tilbage til databasen? hvad vil være mest ansvarligt?

på forhånd tak
Avatar billede arne_v Ekspert
16. august 2017 - 16:01 #1
Alle serioese databaser understoetter samtidige opdateringer fra flere traade.

Det kan virke fint. Men der er nogle ting man skal tage hoejde for.

Et noegle begreb er "transaction isolation level".

For en hurtig intro se:

http://www.vajhoej.dk/arne/articles/dbconcur.html

Saa du kan godt kade de enkelte task skrive tilbage til databasen, men du skal goere det rigtigt for at undgaa problemer.
Avatar billede arne_v Ekspert
16. august 2017 - 16:02 #2
Med hensyn til styring af dine tasks, saa lyder det som noget en helt almindelig ThreadPool kan klare fint.
Avatar billede Droa Seniormester
16. august 2017 - 18:26 #3
mange tak for det brugbare link, jeg har dog valgt og bruge GUID istedet for et integer, da jeg har haft auto-generate id problemer førhen, så jeg prøver altid og inserte med et nyt GUID, og hvis GUID'et så findes, prøver den og danne et nyt.

og jo jeg mente os TreadPool, tror min hjerne hoppede over i java i nogen få sekunder der.

men jeg er glad for min ide ikke kun virker som ide, men os i Theori, nu håber jeg bare os det os virker i praksis, når jeg når så langt, mange tak for indput Arne_v
Avatar billede arne_v Ekspert
16. august 2017 - 21:45 #4
Auto increment burde virke, men GUID er ogsaa fint. Hvis du vil styre det i applikationen, saa er der high-low metoden.

.NET thread pool og Java thread pool er ret ens.
Avatar billede Droa Seniormester
16. august 2017 - 22:18 #5
når du siger High-Low, menter du så dette?
https://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm

Det var mere fordi java engang havde ThreadGroup, som jeg mener nu er depricated, at jeg kom til og sige ThreadGroup istedet for ThreadPool, som hurtigt kunne havde givet problemer ;)
Avatar billede arne_v Ekspert
17. august 2017 - 02:25 #6
Ja. Omend beskrivelsen er ret daarlig.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester