Hirdetés
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: Kell-e manapság egérpad vagy sem?
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Meggyi001: Kórházi ellátás: kuka vagy finom?
- sh4d0w: Kalózkodás. Kalózkodás?
- bitpork: 2025, zárás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Elektromos rásegítésű kerékpárok
-
LOGOUT

Új hozzászólás Aktív témák
-
inf3rno
nagyúr
Az van, hogy 100-asával szórjuk be tranzakcióba az egymástól nagyjából független SQL-eket, aztán így kötegelve küldjük be az adatbázisba, mert így nem ül le tőle az adatbázis szemben azzal, ha egyesével küldjük be őket. Aztán ha valamilyen SQL hibára fut, akkor elnyeljük a hibát, hogy ne veszélyeztesse a teljes tranzakciót. Ha mondjuk out of range okozza a hibát, akkor rendben bekerülnek a változtatások commitnál egyedül azt hagyja ki, aminél a hibát dobta. Azoknál a kivételeknél, mint pl. deadlock, ahol elszáll a teljes tranzakció, ott muszáj újrapróbálni az egészet, hogy ne legyen adatvesztés. Aztán ezért kellett különbséget tennem a két hibatípus között. De közben találtam egy drupal kódrészletet, ami alapján megírtam a saját ellenőrzőt hozzá, úgyhogy rendben van. Most várom az out of range hibákat, mert enélkül a fejlesztés nélkül esélytelen volt debuggolni őket. A deadlockra már nagyjából rájöttem, hogy mi okozhatja, de nem javítható, teljesen újra kellene tervezni az egész rendszert hozzá. Úgyhogy ma sem unatkozom.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 55992Ft+ÁFA
- Gamer szék ASUS ROG Destrier Ergo SL400
- Eladó Realme gt neo 2 5g Dobozában tokkal
- Samsung Galaxy Z Fold6 Navy Duplakijelzős produktivitás, 120 Hz, Galaxy AI,2027. 09. 19
- Bomba Ár! Lenovo ThinkPad L15 Gen2 AMD - Ryzen 7 I 16GB I 512SSD I 15,6" FHD I HDMI I W11 I Gari!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest


