da, nisam opisivao cijeli sistem jer mi ostatak radi i nije sporan.
ali je, to je workflow: useri rade subscriptions raznih dogadjaja u buducnosti. sve to zavrsi u bazi. kasnije, drugi proces cita te dogadjaje i odradjuje.
ovo sto si naveo
Citat:
Originalno napisao Gruja
Jedno rešenje jeste da upisuješ događaje u bazu, a drugi proces/thread da čita periodično bazu i da gleda šta ima novo. Koliko je to opterećenje za bazu - zavisi od raznih faktora, a može da bude problem ako hoćeš svake sekunde da čitaš, a posle i da radiš update. Ako performanse nisu problem možda ti to nije loše rešenje da ne bi sad uvlačio i MSMQ u priču.
|
to je ovo:
Citat:
Cini mi se da ce sve ici u smjeru da odredimo uvjet da korisnik mora narucit svoj gablec barem minutu prije dostave (inace ce se smatrati da zeli promptnu dostavu sto ce onda raditi druga funkcija). Nakon toga, windows service moze mirno:
- pokupiti listu novih narudzbi iz baze svakih npr 30 sekundi i dodati u job queue
- timer.tick sa tick periodom od sekunde odradjivati taskove
- svaka obrada narudzbe ide u svom threadu
ovo mi zvuci kao najcisca i najsigurnija implementacija
|
i tim smjerom cu i ici. najsigurnije mi je.
moja dilema je bila bas to sto kazes:
Citat:
|
Četvrto je ovo što si pominjao za Windows scheduler, ali stvarno ne znam kako se ponaša kad mu se preko nekog apija stalno kreiraju i brišu taskovi i kako se nosi sa većom količinom događaja.
|
PS.
performanse ovog rjesenja su rjesive tako sto znam da mi se predbiljezba za dogadjaj nece desiti unutar posljednje minute samog dogadjaja. to znaci da mogu komotno staviti da se svakih 45 sekundi iz baze dovlaci lista dogadjaja koje treba odraditi u npr. slijedecih sat vremena. a onda timer ima tick svaku sekundu, dvije, tri (nebitno) i prolazi kroz listu dogadjaja i okida one kojima je dosao cas.