Ponera två eller flera olika samtidiga Disgenklienter mot en och samma databas? Då lär väl någon låsningsmekanism på någon nivå behövas.
Ponera två eller flera olika samtidiga Disgenklienter mot en och samma databas? Då lär väl någon låsningsmekanism på någon nivå behövas.
Høres ut som noen ønsker vil medføre behov for en multitier-løsning ?
Kurant å lage i Delphi. Problemet er å bestemme seg for hva slags løsning, minst 3 forskjellige varianter out-of-the-box, men mest populært en REST-løsning for tiden.
Alf Christophersen Disgen fadder Norge.
Riktigt. Det finns en tabell i databasen där Disgen skriver en installationsunik identifierare. Finns denna i databasen betraktas den som låst av Disgen. När Disgen avslutas tas raden bort och databasen betraktas som olåst. Kraschar Disgen står raden kvar, men vid nästa start kan Disgen se vem som skrev den och då antingen fråga användaren om låset ska brytas eller ta bort låset med automatik.Ursprungligen postat av BrJohan
Vice ordförande (2025) & Disgenutvecklare.
Som svar: bra! Som semaforprincip: diskutabel - men betydligt bättre än ingen. Vore inte utnyttjande av faciliteterna i WAL (Write Ahead Logging) att föredra? (SQLite >= 3.7 förmodas)
Borde möjlighet att exekvera Disgen i 'read-only' läge finnas?
Inser inte riktigt hur det skulle påverka semaforprincipen som sådan, det gör det väl knappast? Men om du menar att Disgen borde klara samtidiga användare så är det rätt många andra saker i koden som effektivt förhindrar detta, i alla fall i dagsläget. Det är i alla fall inte något som enbart kan lösas på databasnivån.
Det finns möjlighet att köra disgen readonly men det fungerar bara nästan. Om man in den situationen jag nämnde väljer att inte bryta låset så hamnar Disgen i readonly-läge men man får vara beredd på en och annan krasch. Det ska vi nog kunna reparera med tiden.
Även 8.2 fanns faktiskt i en särskild läsversion, men den fick aldrig någon spridning. Där var alla spärrar gjorda i användargränssnittet och resultatet blev inte så värst bra.
Vice ordförande (2025) & Disgenutvecklare.
För att den aktuella semaforprincipen skulle ha varit säker, hade läsning och skrivning av tabellraden behövt vara en atomär operation (jämför 'Compare-and-swap' eller 'Test-and-set').
Å andra sidan används ju Disgen inte - som tur är - i några säkerhetskritiska sammanhang.
Säkerhetskritisk släktforskning, ja det hade ju varit något.
Nu finns det i och för sig ytterligare lås som förhindrar att två instanser av Disgen öppnar samma datamapp, och där används existensen av en namnad mutex som lås. Det blir vattentätt så länge man är på samma maskin. Jag tror dessa mekanismer tillsammans blir tillräckligt bra i förhållande till vad vi vill uppnå...
Vice ordförande (2025) & Disgenutvecklare.
Behörigheter för att posta
Svara med citat