Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Har du brugt LOCK TABLES inden du fik fejlen? Tabellen bliver jo låst, og så kan du ikke samtidig køre forespørgsler fra andre threads end den ene, der låste tabellen.
Det er vel den mest sikre måde for at holde tabellerne intakte er det ik?
Ellers kan der jo komme en ændring ind imellem 2 queries, og man vil måske ikke få det korrekte resultat.
Vil det være sådan, at kommandoen (mysql_query("LOCK... osv)) vil blive sat på stand-by indtil den anden bruger er færdig med at arbejde på tabellen? Det er jeg nemlig noget i tvivl om...
Jamen hvad er det for en forespørgsel du har tænkt dig at køre, hvor ingen ændringer må være sket i databasen? Jeg har personlig aldrig brugt det til andet end replikation.
En bruger (eller koden dertil) tæller op i en tabel: - Hvor mange rækker der er i tabellen i alt - Hvor mange rækker der er i tabellen der har "Y" i en bestemt kolonne - Hvor mange rækker der er i tabellen der har "Y" i en anden bestemt kolonne
Her gå admin så ind og tilføjer et produkt indimellem. Så giver det problemer - det kan da ske i masser af tilfælde. Jeg ved godt at de ikke vil ske ret tit, men jeg vil afluse denne "ikke ret tit" til aldrig.
Det SKAL kunne lade sig gøre, ellers fandtes det vel ikke - og der er jo en god mening med at bruge det.
Jamen brugeren vil jo blot have fået sit resultat. Hvordan har brugeren adgang til databasen? Er det via en hjemmeside eller et program?
Hvis brugeren kun har adgang til databasen gennem en hjemmeside, så vil hans forespørgsel jo blot blive besvaret. Sker der så ændringer vil han først få dem vist når han reloader siden i sin browser. Når siden så indlæses igen, så vil det nye produkt blive vist.
Hvilken type db har du oprettet? MyISAM, BDB, ...?
Selvfølgelig kan det lade sig gøre, men der er ikke grund til at låse tabellerne i tide og utide, hvis det kan undgås.
Nej, du skal forestille dig at de 3 forespørgsler sker på samme site, så vil det rigtige resultat ikke komme ud, for netop hvis tabellerne ikke er låst kan en anden person gå ind og påvirke tabellerne indimellem de f.eks. 3 jeg har skrevet 2 kommentarer oppe.
Det er rigtigt, men hvor mange brugere regner du med at have? og hvor mange opdateringer? Chancen for at det skulle gå galt vil sandsynligvis være forsvindende lille. En anden ting der er værd at overveje er, hvor galt det vil gå, hvis det skulle ske. Altså om det går ud over database-integriteten, eller om der blot mangler et produkt i e-handlen, som tilmed vil blive vist, så snart brugeren har trykket på et link...
Bruger du den samme thread til både LOCK og UNLOCK? Eller sker det via forskellige tråde? Du skal jo huske at bruge den samme forbindelse, så måske du skulle overveje en persistent connection, for at kunne bruge den samme tråd igen.
Det her var hvad der stod i manualen, "The main reasons to use LOCK TABLES are for emulating transactions or getting more speed when updating tables."
Der stod også følgende, "If a thread obtains a READ lock on a table, that thread (and all other threads) can only read from the table. If a thread obtains a WRITE lock on a table, only the thread holding the lock can read from or write to the table. Other threads are blocked."
Du skal måske bruge en WRITE lock i stedet. Du har jo netop tænkt dig at opdatere indholdet ikke sandt?
samme thread ... ja, det gør jeg vel, det er i samme script...
Men en anden (i en anden tråd) kan jo godt ske at forsøge at låse tabeller der er låst.
Jeg ved ikke hvad en persistent connection er? Vil du forklare?
Jeg har styr på READ og WRITE, men det er blot i nævnte tilfælde der skulle stå READ. Og jeg har læst manualen, men der står ikke noget om mit spørgsmål.
Hmm... en persistent connection er en forbindelse, har ikke så meget med databasen at gøre, men mere med det program/sprog du bruger til at oprette forbindelse. I php bruger man f.eks. mysql_pconnect()-funktionen i stedet mysql_connect()-funktionen. Det resource link der så bliver skabt, er gældende for den thread, og de lukkes først når du beder om det. F.eks. med mysql_close($link_id).
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.
