Recover hibakezelési stratégia kérdés
Tisch Dávid
Sziasztok!
A következő a jelenség: van egy "Yes - After updating record" megállási feltételű batch taszkom (vagyis ami csak egyszer fut le), aminek a hibakezelési stratégiája "Recover". Ez a taszk - sok minden egyéb mellett - hív egy ilyet: "INIPut('[MAGIC_ENV]HTTPTimeout=10','FALSE'LOG)" (vagyis egy 10 mp-es timeout állítás), utána pedig van egy HTTPPost hívás, aminek a beküldött paraméterei között van egy, aminek GUID-nak (világegyedinek) kell lennie, és sosem szabad beküldeni kétszer ugyanazt, semmilyen körülmények között.
A szerver oldal üzemeltetői szerint a beküldött adatok ~0,01%-ban előfordul, hogy mégis kétszer küldjük be ugyanazt, olyan esetekben is, amikor ez a paraméter egy, a hívás előtt helyben a Rand() függvénnyel generált véletlen szám. További érdekesség, hogy a dupla beküldések között mindig valamivel több, mint 10 mp telik el.
Másra nem tudván gondolni, felmerült bennem, hogy nem lehet-e, hogy a küldés során fellépő valamilyen magices hiba miatt aktiválódik a Recover hibakezelési stratégia, ami miatt a HTTP kérés - változatlan formában - mégegyszer elküldésre kerül. (Nem tudom sajnos, hogy pontosan hogyan működik a Recover. Mit ismétel, ha ismétel? Az egész record suffixet? Vagy csak az adott utasítást?) Kínomban arra gondoltam, hogy kitenném a küldést egy külön programba, aminek Abort lenne a hibakezelési stratégiája.
Van tapasztalatotok a "Recover"-ről? Okozhat az ilyesmit? Az általam vázolt megoldás segíthet Szerintetek?
Előre is köszönöm a segítségeteket!
Üdvözlettel:
Dávid
Bakos Gyula
Szia!
Gondolom, nincs is tranzakciód ebben a taszkban akkor?
Nekem eddig csak tranzakciós taszkban volt tapasztalatom a Recover / Abort beállítással, és a tapasztalat az, hogy ha tranzakció van, akkor Abort-ra érdemes állítani.
Érdekes, amit írsz, mert a jelek szerint nem tranzakciós taszk esetén is okozhat bonyodalmat a Recover.
A GUID azonosítót egyébként te generálod?
Gyula
--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „Magic Support Levelezőlista” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) magic-suppor...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/magic-support/55cec578-9e0b-b4b1-a9c9-38b689518385%40drpinterkft.hu.
Tisch Dávid
Szia Gyula!
Köszönöm a válaszodat! Csak adatolvasás van ebben a taszkban, de
a locking strategy az immediate, a transation begin pedig on
record lock, úgyhogy az gondolom, hogy van tranzakció van ebben a
taszkban, ha sok értelme nincs is.
Ebben az esetben van valami ötleted/tapasztalatod?
A GUID egy részét a beküldendő adat kódjából állítom elő, de van
egy Rand()-dal generált suffix, éppen azért, hogy - abban az
esetben, ha a többszöri beküldési kísérlet valid - ne legyen 2
egyforma ID.
Üdvözlettel:
Dávid
Bakos Gyula
Szia!
Az a tapasztalat, hogy hiába van tranzakció beállítva egy taszkban, ha nincs írásra nyitott tábla, akkor a Magic nem indít tranzakciót az adatbázis felé.
Ha nem kell adatrekordot írni, akkor Lockolást nem szoktunk beállítani, mert az csak fölöslegesen szaporítja az egyébként is előforduló Lockolt rekordra várakozások számát (Waiting for locked row, table tbl_name).
Más kérdés, hogy a Magic számára jelentheti azt a beállított tranzakció írásra nyitott tábla nélkül is, hogy tranzakció van, amit hiba esetén Recover beállításnál meg kell ismételni. (El tudom képzelni, hogy ilyen hibaként érzékelheti a Magic pl. a Lockolt rekordra várakozást is)
Néha adatolvasás miatt is szükség lehet tranzakció (Within active) beállítására, hogy a már fölsőbb taszk-szinten megkezdett ranzakció „részeként” lássa a taszkunk a még nem kommitált adatmódosításokat. Én ilyen esetekben is a Locking-ot No-ra szoktam tenni, ha jelen taszkban nem történik adat írás. Csakis akkor állítok be Lockolást, ha adat írás történik.
A te esetedben először a Lockolás No-ra állításával próbálkoznék. Ha az adatolvasás és fölsőbb szinten beállított tranzakció nem indokolja, akkor a Tranzakciót is No-ra állítanám. Ebben az esetben várhatóan a Recover sem fogja már a jelenlegi problémát produkálni.
Ha esetleg mégis, akkor a GUID generáláskor és HttpPost-al kiküldésével együtt letárolnám egy külön kis tranzakciós taszkban adatbázisba a generált GUID-ot. A HttpPost-ot kitenném egy Util programba, ahol leellenőrizném, hogy a kapott GUID-ra ment-e már ki HttpPost, és ha igen, akkor visszatérnék a hívó helyre egy új GUID generálásra, és újbóli hívásra.
Gyula
From: magic-...@googlegroups.com <magic-...@googlegroups.com> On Behalf Of Tisch Dávid
--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „Magic Support Levelezőlista” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) magic-suppor...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/magic-support/2f1e615c-1b27-1ad9-4251-449120e60b8b%40drpinterkft.hu.
Tisch Dávid
Szia Gyula!
Köszönöm a válaszodat! Ez a külön taszkba kihelyezett HTTPPost
hívás újbóli GUID ellenőrzéssel alapvető jó ötletnek tűnik, a baj
csak az, hogy hogyan kezeljem azt az esetet, ha rájövök, hogy már
volt ilyen GUID (tegyük fel, hogy egy Recover miatt)?
Azt nem csinálhatom, hogy visszatérek és generálok újabb GUID-ot aztán küldöm megint, mivel nem önmagában a GUID-nak kell egyedinek lennie, hanem az adatbeküldés, amihez a GUID tartozik. A GUID csak ellenőrzési célt szolgál, hogy szerver oldalon kiszűrhessék az ilyen típusú hibákat.
Az a baj, hogy Magic oldalon lesz egy hiba (ha egyáltalán ez a jelenség oka), amit ő újrajátszással próbál javítani, de a csak egyszer végrehajtható HttpPost hívás egyébként sikeresen megtörtént, így azt nem szabad mégegyszer megismételni, a válasz azonban - a fellépő hiba miatt - elveszett, tehát nem tudjuk felírni, hogy mi történt.
Van erre a problémára vajon Magicben írt megoldás?
Köszönettel:
Dávid
Szia!
Az a tapasztalat, hogy hiába van tranzakció beállítva egy taszkban, ha nincs írásra nyitott tábla, akkor a Magic nem indít tranzakciót az adatbázis felé.
Bakos Gyula
Szia!
Meg lennék lepve, ha a Magic fel lenne készítve az ilyen esetekre.
Meg kellene fontolnod, hogy megoldaná-e a problémádat, ha a Recover-t kikapcsolnád.
Illetve, az lenne a jó, ha valahogy le tudnád kérdezni ilyen esetben, hogy a HTTPPost rendben ki lett-e küldve, illetve az adott GUID-ra nem lehet lekérdezni, hogy át lett-e küldve vele request?
A 10 másodperc egyébként nagyon gyanúsan valami request timeout, vagy valami egyéb timeout. Nem lehet hogy valami ilyen timeoutból fut ki a hívás valamiért? Lehet hogy megoldaná a problémát, ha ezt följebb lehetne venni?
Gyula
From: magic-...@googlegroups.com <magic-...@googlegroups.com> On Behalf Of Tisch Dávid
Sent: Friday, August 7, 2020 6:49 PM
To: magic-...@googlegroups.com
Subject: Re: [Magic Support] Recover hibakezelési stratégia kérdés
Szia Gyula!
--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „Magic Support Levelezőlista” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) magic-suppor...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/magic-support/3e8feeb4-0dd8-1f99-d078-0613bf4bfdaa%40drpinterkft.hu.
Tisch Dávid
Szia Gyula!
Igen, én is attól félek, hogy a Magic nem erre van kitalálva. Lehet, hogy ki fogjuk kapcsolni a Recover-t, mert az ilyen indefinit viselkedés elég ellenjavallt.
Az a baj, hogy a jelenlegi felállás szerint az orvosi rendszereknek egyre inkább a lelke ezzel a központi rendszerrel való kommunikáció, ami bizonyos műveleteket - pl. recept kiadás - jelentősen lelassít azzal, hogy minden adatot fel kell küldeni a térbe. Ha csak 1 mp a teljes webes kommunikáció Magic + PHP oldalon, akkor az elég elfogadható sebesség, de így 20 recept kiadása + 20 mp, ami nagyon sok. Ezt nem lehet tovább terhelni plusz lekérdezésekkel. Ráadásul ez a kommunikáció előírtan szinkron kell, hogy legyen, szóval a párhuzamosítás sem segít.
Mi is azt gondoljuk, hogy az a 10 mp-es újraküldési idő valami timeout lehet, például a a HTTP küldés előtt Magic oldalon kiadott timeout ideje. Mi is azt gondoljuk, hogy talán akkor léphet fel ilyen probléma, ha a kommunikáció megszakad, és a magices timeout lövi le a kommunikációt. Ebből következően viszont ezt a limitet nem merjük feljebb állítani, mert akkor az alkalmazás ilyen esetekben több, mint 10mp-re "lefagyna". Ez performancia szempontjából sem jó, másrészt ha a felhasználó közben még kattint is 1-2-t a felületen, akkor ezzel azt is el tudja érni, hogy a Magic tényleg leálljon. Szóval valószínűleg marad a 10 mp. :(
Köszönettel:
Dávid
Szia!
Meg lennék lepve, ha a Magic fel lenne készítve az ilyen esetekre.
Polgár Ferenc
Már majdnem agyvérzést kaptam az MSSQL-től, mert egy INT mezőt kellett
átalakítanom úgy, hogy 2 tizedest is tudjon tárolni.
(Nem vagyok SQL szakértő, de az MSSQL-t különösen nem csípem.)
Ezt nagy keservesen kiizzadtam (MySQL-ben 1 perces feladat lett volna),
de Magic-ből nem vagyok képes végrehajtatni ezt:
declare @tempvar varchar(100);
declare @SQL varchar(1000);
SET @tempvar = (SELECT OBJECT_NAME(constid) as Myconst FROM sysconstraints
WHERE id=OBJECT_ID('Befiz_sor') AND COL_NAME(id,colid) = 'Osszeg');
IF @tempvar<>''
BEGIN
set @SQL = N'ALTER TABLE Befiz_sor DROP CONSTRAINT '+@tempvar;
EXECUTE (@SQL);
END
ALTER TABLE Befiz_sor
ALTER COLUMN Osszeg Decimal(10,2) NOT NULL;
Úgy tűnik, hogy csak 1 sort hajlandó végrehajtani. Nem tudom, hogy jól
látom-e?
Van valamilyen megoldás, hogy ezt végre tudjam hajtatni, vagy kézzel
kell lefuttatni a scriptet az MS SQL Management Studio-ban?
Előre is köszönöm az ötleteket.
üdv
Feri
Tisch Dávid
Szia Feri!
Én a következőt csinálom, egymást követő direkt SQL taszkokban:
- - - - - - - - - - Tranzakció indítás - - -
- - - - - - -
BEGIN TRANSACTION;
- - - - - - - - - - Default érték constraint
törlése (1. paraméter: táblanév, 2. paraméter: oszlop név) - - -
- - - - - - -
DECLARE @constraint SYSNAME, @sql
NVARCHAR(MAX);
SELECT @constraint = obj.name
FROM sys.columns col
LEFT JOIN sys.objects obj ON obj.object_id =
col.default_object_id and obj.type = 'D'
WHERE col.object_id = object_id(N'dbo.:1') AND col.name = N':2'
and obj.name is not null;
SET @sql = N'ALTER TABLE :1 DROP CONSTRAINT ' + @constraint;
EXEC sp_executesql @sql;
- - - - - - - - - - Maga az ALTER utasítás (1. paraméter: tábla név) - - - - - - - - - -
ALTER TABLE dbo.:1 ALTER COLUMN ColumnName float DEFAULT 0 NOT NULL;
- - - - - - - - - - Lezárás - - - - - - - - - -
COMMIT; vagy ROLLBACK;
Üdvözlettel:
Dávid