Thread-Safe List v jave

[xavier]

Vyuziva sa trieda zo springu deferred result, ktora zabezpeci to, aby dany objekt bol vrateny ako response az ked sa mu nastavi result. Tym ze tieto objekty drzim v kolekcii, mozem im nastavit result kedy to je potrebne, a vtedy je vysledok vrateny uzivatelovi.

To ale pořád není důvod držet requesty v kolekci. Přece nějak zjistíte, že máte co uživateli vrátit – buď na to čekáte, tak můžete mít ten deferred result uložený u toho čekání, nebo ty odpovědi chodí nějak úplně nezávisle (např. na chatu – „pošli zprávu uživateli XY“), ovšem pak zase musíte umět identifikovat, kam se má poslat ta odpověď, a hodila by se spíš mapa, kde by byl klíč ten identifikátor a hodnota ten response. Netvrdím, že nemůže být případ, kde je vhodné použít list, ale nic moc takového mne nenapadá. Snad jen kdybyste chtěl uživateli zobrazit frontu jeho požadavků, jak postupně přicházely, nebo chtěl postupně v pořadí zpracovat všechny požadavky uživatele. Ale to neodpovídá tomu deferred result.

Len aby sme sa spravne pochopili, tymi requestmi myslim deferred result objekty. ak uzivatel posle poziadavok na data, vytvori sa pre daneho uzivatela deferred result a ulzi sa do kolekcie az kym nie su pre neho nove data. Ako nahle su, tak sa deferred result objektu nasetuju dane data a ten sa potom vrati uzivatelovi ktory sa na ne poptaval. Deferred result sa potom zmaze pre daneho uzivatela z mapy.

[Reklama]

[Filip Jirsák]

Len aby sme sa spravne pochopili, tymi requestmi myslim deferred result objekty. ak uzivatel posle poziadavok na data, vytvori sa pre daneho uzivatela deferred result a ulzi sa do kolekcie az kym nie su pre neho nove data. Ako nahle su, tak sa deferred result objektu nasetuju dane data a ten sa potom vrati uzivatelovi ktory sa na ne poptaval. Deferred result sa potom zmaze pre daneho uzivatela z mapy.

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

Jinak pokud je to asynchronní webový kontrolér, pozor na to, že tam je ta asynchronnost určená pro to, aby se zbytečně neblokovalo vlákno třeba při čekání na data z databáze nebo z nějaké webové služby, tedy pro věci, které by měly být vyřízené během pár vteřin. Z pohledu prohlížeče/klienta je to pořád synchronní komunikace, takže jakmile prohlížeč odešle poslední bajt požadavku, zapne stopky a měří timeout do prvního bajtu odpovědi – a pokud se nedočká ve stanoveném limitu, spojení resetuje a zobrazí chybu.

Pokud byste chtěl skutečně asynchronní komunikaci (např. chat), kde odpověď může přijít třeba za 5 nebo taky za 15 minut, je potřeba použít buď Server-sent events nebo WebSockets. Pro WebSockety má Spring také dobrou podporu včetně fallbacku pro staré prohlížeče, které WebSockety nepodporují.

[xavier]

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

iny uzivatel odosle data na server kde je priznak prijimatela, na zaklade ktoreho su data v mape

[Filip Jirsák]

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

iny uzivatel odosle data na server kde je priznak prijimatela, na zaklade ktoreho su data v mape

Podle toho se vybere klíč v mapě. A položka v seznamu se vybere jak? Má to být fronta, takže vždy první položka?

Pokud se s odpovědí čeká na jiného uživatele, asynchronní requesty podle mne nejsou dobrá volba. Použil bych ty WebSokety, ty jsou na takovouhle komunikaci přesně určené. Ve Springu je nad tím podpora pro protokol STOMP, případně od Webtide existuje CometD, které lze také propojit se Springem. Obojí řeší předávání zpráv konkrétním posluchačům, takže nemusíte řešit právě to, které spojení je kterého uživatele.

[xavier]

No a jak se pozná to, že už data pro uživatele jsou? A jak budete hledat response, ke kterému ta data patří?

iny uzivatel odosle data na server kde je priznak prijimatela, na zaklade ktoreho su data v mape

Podle toho se vybere klíč v mapě. A položka v seznamu se vybere jak? Má to být fronta, takže vždy první položka?

Pokud se s odpovědí čeká na jiného uživatele, asynchronní requesty podle mne nejsou dobrá volba. Použil bych ty WebSokety, ty jsou na takovouhle komunikaci přesně určené. Ve Springu je nad tím podpora pro protokol STOMP, případně od Webtide existuje CometD, které lze také propojit se Springem. Obojí řeší předávání zpráv konkrétním posluchačům, takže nemusíte řešit právě to, které spojení je kterého uživatele.

technologicke rozhodnutia nie su v mojej kompetencii, rob to co mam nariadene od veduceho ... kazdopadne otazka nebola aku technologiu zvolit ale aku kolekciu pouzit pre dany problem

[Reklama]

[Filip Jirsák]

kazdopadne otazka nebola aku technologiu zvolit ale aku kolekciu pouzit pre dany problem

Pořád ještě nevíme, jak se z té kolekce bude číst, bez toho se opravdu nedá určit, jakou kolekci použít a zda vůbec použít kolekci.

Navíc pokud nevíte, jakou kolekci použít, měl by vám to snad říci ten vedoucí, ne…

[xavier]

Pořád ještě nevíme, jak se z té kolekce bude číst, bez toho se opravdu nedá určit, jakou kolekci použít a zda vůbec použít kolekci.

ak pridu nove data od nejakeho uzivatela, vezme sa priznak z tych dat, pozrie sa ci mapa obsahuje nejake "cakajuce" requesty, teda uzivatelov ktory cakaju na tieto data, ak ano iteraciou sa kazdemu deferred resultu v kolekcii nastavia dane data

[Filip Jirsák]

ak pridu nove data od nejakeho uzivatela, vezme sa priznak z tych dat, pozrie sa ci mapa obsahuje nejake "cakajuce" requesty, teda uzivatelov ktory cakaju na tieto data, ak ano iteraciou sa kazdemu deferred resultu v kolekcii nastavia dane data

Takže se to má nastavit všem objektům pro daného uživatele a na pořadí nezáleží. A po nastavení dat se předpokládám celá kolekce smaže (respektive kvůli vícevláknovému přístupu by spíš měla naopak nejdřív vyjmout z mapy, aby už se neměnila, a pak nastavit výsledky). V tom případě by stačil Set, ale protože unikátnost je zaručená z povahy věci a není nutné ji kontrolovat, z hlediska výkonu bude asi lepší LinkedList. Buď tedy ConcurrentLinkedQueue, a nebo použít ConcurrentHashMap a její metodu compute a uvnitř už pak běžný nesynchronizovaný LinkedList – to si myslím, že bude v tomto případě nejefektivnější řešení.

[xavier]

ak pridu nove data od nejakeho uzivatela, vezme sa priznak z tych dat, pozrie sa ci mapa obsahuje nejake "cakajuce" requesty, teda uzivatelov ktory cakaju na tieto data, ak ano iteraciou sa kazdemu deferred resultu v kolekcii nastavia dane data

Takže se to má nastavit všem objektům pro daného uživatele a na pořadí nezáleží. A po nastavení dat se předpokládám celá kolekce smaže (respektive kvůli vícevláknovému přístupu by spíš měla naopak nejdřív vyjmout z mapy, aby už se neměnila, a pak nastavit výsledky). V tom případě by stačil Set, ale protože unikátnost je zaručená z povahy věci a není nutné ji kontrolovat, z hlediska výkonu bude asi lepší LinkedList. Buď tedy ConcurrentLinkedQueue, a nebo použít ConcurrentHashMap a její metodu compute a uvnitř už pak běžný nesynchronizovaný LinkedList – to si myslím, že bude v tomto případě nejefektivnější řešení.

zaznamy unikatne predsa nebudu, pretoze uzivatel moze otvorit aplikaciu v novom okne, tie data sa posielaju automaticky, cize duplicity vznikat budu, a je potreba reagovat na vsetky, nemoze sa stat, ze aplikacia zobrazi v jednom okne ine vysledky ako v tom druhom ... kazdopadne dakujem za radu, cize naozaj staci obycajny linked list nesynchronizovany? myslel som ze ak sa vyuziva multithreading musia byt synchronne aj vnorene kolekcie v mape

[Filip Jirsák]

zaznamy unikatne predsa nebudu, pretoze uzivatel moze otvorit aplikaciu v novom okne, tie data sa posielaju automaticky, cize duplicity vznikat budu, a je potreba reagovat na vsetky, nemoze sa stat, ze aplikacia zobrazi v jednom okne ine vysledky ako v tom druhom

Záznamy unikátní budou, protože záznamem je asynchronní požadavek a ten vznikne pokaždé nový.

kazdopadne dakujem za radu, cize naozaj staci obycajny linked list nesynchronizovany? myslel som ze ak sa vyuziva multithreading musia byt synchronne aj vnorene kolekcie v mape

Synchronizované musí být zdroje, ke kterým se přistupuje z více vláken. A v případě ConcurrentHashMap zajistí synchronizaci metoda compute, která se pro daný klíč provádí atomicky.

[xavier]

Synchronizované musí být zdroje, ke kterým se přistupuje z více vláken

No prave, to v pripade Listu v mape bude nie? Ako som spominal ak uzivatel spusti aplikaciu na viacerych miestach zaroven, tak tie deferred resulty sa budu pridavat z viacerych vlaken.

[Filip Jirsák]

Synchronizované musí být zdroje, ke kterým se přistupuje z více vláken

No prave, to v pripade Listu v mape bude nie? Ako som spominal ak uzivatel spusti aplikaciu na viacerych miestach zaroven, tak tie deferred resulty sa budu pridavat z viacerych vlaken.

Ano, ale ten přístup bude synchronizovaný přes mapu. Zapisovat se do toho listu bude pouze v rámci volání metody compute, která zajistí synchronizaci, a číst se bude až po zavolání remove na mapě, takže ten list pak bude ve vlastnictví jednoho vlákna a ostatní už k němu nebudou mít přístup.

[xavier]

Dakujem