Cześć ;) W ramach nauki piszę sobie coś ala mini serwis aukcyjny. Nie wiem jak rozwiązać taki problem - jest oferta, ma ona w sobie obiekt 'bidding' (licytacja) który przetrzymuje informacje o userach biorących udział w licytacji oferty. Teraz załóżmy taki przypadek, że jest oferta mega okazjonalna itp. i masa userów podbija ofertę. Jak to najlepiej zrobić tak aby user podbijał najwyższą ofertę, niekoniecznie akurat tę która mu się wyświetla (np. użytkownik nie odświeżył oferty przez jakiś czas a w tym czasie ktoś ją podbił z 10zł do 20 a on wciąż widzi 10). Myślałem nad optimistic lockiem ale chciałbym uniknąć przypadku, że jest oferta początkowa 10zł, użytkownik A i B znajdują się na niej -> A daje 15zł, sekunde pózniej B daje 20zł i B będzie musiał odświeżyć stronę bo wersja się nie zgadza... A wolałbym zrobić tak, że mimo iż B nie widział zmiany z 10 na 15 ale i tak jego oferta jest większa od 15zł to update leci pozytywnie. Może jakieś kolejka? Chętnie wysłucham Waszych rad :)
-
Jaką strukturę fizyczną planujesz? Ile warstw? baza danych + kod Java, czy tylko jakiś serwis w Javie? Bo wtedy inaczej wygląda dynamika tego, co już przeczuwasz.
-
Ile linii kodu / klas chcesz na to poświęcić. Temat można bardzo twórczo potraktować, aż nawet do wzorca event sourcing, czy kolejek itd...
Ja bym zapisywał każdą ofertę, nawet jak jest niższa, a później bym po prostu robił sortowanie po kwocie(to nam indeks załatwi albo kopiec), a potem po dacie jakby te same kwoty się zdarzyły by wybrać aktualnie najwyższą i najwcześniejszą. Zero blokad, łatwe do implementacji czy to na bazie danych czy w pamięci.
Jaki problem rozwiązuje tutaj kolejka?
Dane wyświetlane na UI niejako z założenia są nieaktualne. Zamiast ustawiać konkretna wartość, można po prostu zwiększać licznik - wtedy nie masz tego problemu. Masz wtedy niestety inny problem - degradacje wydajności z powodu locka na poziomie wiersza. I tutaj zaczyna się robić ciekawie, bo można pochylić się np. nad event sourcingiem (append only, bez mutacji), czyli nagrywasz wszystkie bidy.
AnyKtokolwiek napisał(a):
Jaką strukturę fizyczną planujesz? Ile warstw? baza danych + kod Java, czy tylko jakiś serwis w Javie? Bo wtedy inaczej wygląda dynamika tego, co już przeczuwasz.
Ile linii kodu / klas chcesz na to poświęcić. Temat można bardzo twórczo potraktować, aż nawet do wzorca event sourcing, czy kolejek itd...
bazy danych + java, co do ilości kodu to bez znaczenia - piszę to aby się poduczyć ;)
neves napisał(a):
Ja bym zapisywał każdą ofertę, nawet jak jest niższa, a później bym po prostu robił sortowanie po kwocie(to nam indeks załatwi albo kopiec), a potem po dacie jakby te same kwoty się zdarzyły by wybrać aktualnie najwyższą i najwcześniejszą. Zero blokad, łatwe do implementacji czy to na bazie danych czy w pamięci.
Jak ktoś walnie ofertę niższą niż jest aktualnie najwyższa to nie chcę aby mu ta oferta przeszła ;p
Charles_Ray napisał(a):
Jaki problem rozwiązuje tutaj kolejka?
Dane wyświetlane na UI niejako z założenia są nieaktualne. Zamiast ustawiać konkretna wartość, można po prostu zwiększać licznik - wtedy nie masz tego problemu. Masz wtedy niestety inny problem - degradacje wydajności z powodu locka na poziomie wiersza. I tutaj zaczyna się robić ciekawie, bo można pochylić się np. nad event sourcingiem (append only, bez mutacji), czyli nagrywasz wszystkie bidy.
zwiększać licznik - masz na myśli licznik wersji poprzez założenie optimistic locka? ciekawy pomysł z event sourcingiem, poczytam o tym dokładniej
Chyba nie zrozumiałeś co @neves miał na myśli, a jego propozycja jest właśnie idealna. Zamiast podchodzić do problemu od strony technicznej, zadaj sobie pytanie co chcesz osiągnąć. Jaki jest cel aukcji? Wygrywa (i płaci) ten kto zaproponował najwięcej, najwcześniej. Co za tym idzie, zgodnie z propozycją nevesa "przepuszczasz" przez obiekt wszystkie stawki, bo nie ma znaczenia czy aktualnie któraś jest niższa czy wyższa. Dopiero pod koniec aukcji wybierzesz tę która była najwyższa, a jeśli zdarzy się że będzie ich więcej niż jedna to wygrywa ta która była pierwsza (najwcześniejsza). Z perspektywy użyt89kowników wszystko jest nadal ok- wygrał ten który zaproponował najwięcej jako pierwszy. Bo jak już zostało wspomniano wcześniej, UI wszystkich użytkowników nigdy nie będzie w 100% aktualne ze stanem aukcji, i trzeba to zaakceptować zamiast z tym walczyć.
Myślę że mimo wszystko twój obiekt może jednak nie akceptować absolutnie wszystkich stawek, a odrzucać te która na pewno są mniejsze od aktualnie największej. Innymi słowy, jeśli aktualnie największą stawką jest 99.99 a ktoś zaproponuje 99.98, to zwyczajnie to ignorujesz w obiekcie bo wiesz z całą pewnością że nie jest to największa stawka. Ale nawet jeśli to zaakceptujesz, to nic się nie stanie bo ta niższa stawka i tak nie wygra.
Rzadko to tutaj polecam, ale zainteresuj się DDD i koncepcją agregatów (w znaczeniu DDD a nie jakimś innym). DDD pochodzi do problemów w taki sposób jak zrobił to neves- skupia się na realnej naturze problemu a nie technikaliach.