Er der nogen der ved om man kan aflæse et eller andet connection id i transact-sql for den aktive klient?
Scenariet er noget i stil med, at jeg skal gemme nogle word dokumenter i min database. Når en bruger henter et word dokument ud for at editere i det, skal det registreres at det pågældende dokument låses. Når man er færdig med at editere dokumentet, opdateres det i databasen, og låsen fjernes.
Problemet er, at hvis klient programmet går ned, får man aldrig låst op igen. Derfor var min ide, at man kunne gemme et connectionid når man gemmer låsen, og når man skal checke om noget er låst, checker man om den registreret connection stadig er aktiv.
Der er et process-id, som desværre ikke kan bruges. Dette ID bliver nemlig genbrugt (pga. connectionpooling), så hvis en app crasher og bliver startet igen, får den med høj sandsynlighed samme ID.
Med connection pooling så tror jeg ikke at du kan gøre noget på TSQL niveau.
Du bliver nødt til at lave en lille tabel med: brugernavn dokumentnavn checkudtid leasetid checintid
Og så lade checkud indsætte en række i den tabel efter at have checket om der er nogle stadig valide leases på dokumentet (valid => chekcintid er NULL og nu < checkudtid + leasetid).
Problemet er blot, at den ikke er ret sikker. Sæt nu bruger1 tager længere tid end leasetid på at skrive i dokumentet, og bruger2 i mellemtiden (efter timeout) ændrer noget i dokumentet og gemmer dette. Så vil bruger1 enten overskrive bruger2's ændringer, eller få af vide at han ikke kan gemme pga. timeout.
Timeout giver jo så også et andet problem: Hvis en bruger henter et dokument ud for at skrive i det, og BANG så går hans app ned, så vil han ikke kunne hente dokumentet ud igen før hans første checkout gav en timeout.
Jeg er muligvis på vej ind i en blindgyde her, men der MÅ da være en løsning...
Lease tid skal sættes rimelig højt. Fordi under alle normale omstændigheder annuleres leasen jo ved checkin.
Man kan jo lave det sådan at samme bruger kan checke ud igen.
Det er helt normalt at source control systemer låser filene til en bestemt bruger indtil den eksplicit releases.
Den teknok bruges af millioner af brugere over hele verden, så det virker i praksis. En lille finesse således at låse udløb efter f.eks. 24 timer er så en ekstra lille finesse. Jeg vil nok iøvrigt anbefale at checkin blokeres hvis lease er udløbet.
Det er helt rigtigt at source control systemer benytter denne metode, så som SourceSafe, Perforce og CVS. Men det er ikke et source control system jeg laver, og jeg er ikke sikker på, at teknikken er helt rigtig i min situation. I tidligere versioner af vores software ligger alle dokumenter i filsystemet, og kun stien er registreret i databasen. Her har man fordelen af, at Windows selv håndterer samtidig brug af samme fil, så når man launcher Word får man af vide, at en anden bruger har dokumentet åbent, og at man derfor ikke kan editere det. Hvis en app går ned, frigives "låsen" i windows derfor automatisk. Jeg er ret sikker på, at jeg ikke får den store tilslutning til explicit checkout/checkin løsninger, når nu brugerne plejer at slippe lettere...
Jeg har fundet ud af, at jeg muligvis kan bruge Login_time sammen med connection ID'et, da login_time jo trods alt bliver opdateret når en connection bliver genbrugt.
Nu er problemet så bare, at det ser ud til visse apps ikke holder sin connection hele programmets levetid, men laver connect ind imellem. *SUK*
/DMK
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
