Félreértés ne essék, a neptun szerintem is egy istenverte bughalom (azzal együtt, hogy amikor én kezdtem, akkor még terminálszerveres izé volt, aminél mostmár sokkal sokkal jobb), azon sírva röhögtem, hogy a párhuzamos userszám bugot (vagyis, hogy van egy session limit, azt ha nem férsz be, próbákozhatsz, hátha leszakadt valaki, vagy végzett) úgy oldották meg, hogy egy kliens oldali js pár másodpercenként újra próbálkozik , a loginablak felett meg számolja, hogy "n / 30. kísérlet".
Ezzel együtt jó eséllyel kissé bonyolultabb struktúrát kell buzgerálni és lockolni, adott esetben rollbackelni, mint egy tábla egy rekordját, adott esetben akár nem is dbben, mert ott van valahol az application logicban (ráadásul gondolom szempont, hogy de legyen már olyan, hogy mindenféle extra bizgenytűk meg lokális átrendezések is lehessenek, és ehhez ne kelljen fejleszteni pár hónapot a vendornak, ami tipikusan nem segít a hatékony adatbázisnak). Szóval azért ne ess abba a hibába, hogy egy egyszerű, optimálisan szervezett adatbázisnak estében nézed a problémát. Én is úgy gondolom, hogy lehetne ezt valószínűleg gyorsabban/jobban is, pusztán arra akartam kilukadni, hogy azért a 10 user akar egyszerre valamit, az messze nem igaz. Azt meg továbbra is tartom, hogy a hát nem kell lockolni, mert úgyis kicsi a valószínűsége, az nagyon nem jó megközelítés. (Hint, pl volt egy kisebb net hickup, valami tcp stack megfogta kicsit, majd mikor kiegyenesedik, akkor kvázi egyszerre érkezik az addig felgyűlt pár kérés)