Java

Kako napraviti stek univerzalnim za rad ne samo sa Integer, već i sa String i prilagođenim objektima?

Šta treba imati na umu prilikom kreiranja indeksa na velikoj tabeli u produkciji?

Napišite svoju klasu koja implementira stek, sa metodama push, pop i peekMax, koja će vraćati maksimalni element u steku u O(1).

Zašto je potreban SELECT FOR UPDATE umesto synchronized? I zašto pesimistično zaključavanje, a ne optimistično?

Šta uraditi ako processFile ne uspe da se izvrši nakon potvrde transakcije?

Zašto će doći do StackOverflowError ako nema lokalnih promenljivih? Čime će se popuniti memorija?

Zašto ne možemo jednostavno koristiti jednu promenljivu max umesto drugog steka?

Postoji sistem koji omogućava korisnicima da rade sa fajlovima u pretraživaču. Standardni stek je: Java, Spring, React, Postgres. Fajlovi se čuvaju u fajl sistemu na backend-u, metapodaci fajlova u bazi podataka. Tim je implementirao funkciju: @Transactional public void process(String oldName, String newName) { Long id = exec("select id from file where name='" + oldName + "'"); //izvršavanje upita u bazi podataka processFile(oldName, newName); //preimenovanje fajla na disku exec("update file set name='" + newName + "' where id = " + id); //izvršavanje upita u bazi podataka }

Може ли да се оптимизује стек по памети да не буде x2 потрошње?

Има бекенд, постоји кориснички интерфејс. Стек технологија је стандардни: Java, Spring, React, Postgres. Задача: Пројектовати REST ендпоинт који треба да преузме податке из 3 извора и да их врати на UI, обезбеђујући што је могуће већи капацитет и што је могуће мање време одговора (критеријуми макс/мин према нашим конкретним условима, јер у суштини нема магичног решења и треба наћи компромис). Познато је да ће очекивани врхунац RPS за овај ендпоинт бити 200. Детаљи о изворима: 1. Извор - наша база података, упит траје око 15 секунди. 2. Извор - сродни REST сервис, деградира до 2 минута при 100 RPS, у нормалном режиму одговара за 5 секунди. Не можемо променити његово понашање. 3. Извор - сродни REST сервис, одговара насумично (није успостављен образац) са 503 грешкама, у нормалном режиму одговара за 10 секунди. Не можемо променити његово понашање.

Koju vrstu indeksa koristiti za pretraživanje po sredini ili na kraju niza (LIKE '%tekst%')?

Napišite vrlo jednostavnu metodu koja će prilikom rada baciti StackOverflowError.