[ DB ] Hoe doe ik dat met locken?

[Verwijderd]

Ik vraag heel even aandacht voor iets wat ik heel moeilijk vind:

We hebben een remote database connection over het internet via MSADO. Onze VB applicaties gebruiken die databases. Meerdere gebruikers kunnen deze applicaties tegelijk gebruiken.

Nou komt het probleem natuurlijk dat je niet wil dat een gebruiker een gegeven aan het bewerken is, terwijl de andere gebruiker dat gegeven op hetzelfde moment weggooit

Dat is heel mooi, daarom is record locking uitgevonden, de ene gebruiker drukt op bewerken in de applicatie, en een andere gebruiker mag dan niet meer bewerken. Dat is leuk met een continue verbinding naar die database, maar met deze remote verbinding heb je dat niet, en kan je dus geen table locks zetten.

Nou had ik dat dus mooi zelf geprogrammeerd, een eigen database waar een record wordt weggeschreven van "Ik bewerk nu dit record", als een andere gebruiker wil editen wordt eerst in deze tabel gekeken of dat mag, anders heeft ie pech.

Nou heb ik ook een baas, die dat geen mooie oplossing vind en een standaard oplossing wil hebben voor dit probleem. Ik zoeken en zoeken op internet, maar kan niks vinden. Na mijn mening is er geen manier om met een disconnected verbinding standaard record locking te handhaven.

Nog even wat technische info:

Database server : Windows 2000
Database : MS SQL Server 7
Cient app's : VB
DB Verbinding : Remote ADO ( Via IIS MSADC )

Iemand enig idee

[whoami]

Op vrijdag 04 januari 2002 10:42 schreef apottjewijd het volgende:
Nou heb ik ook een baas, die dat geen mooie oplossing vind en een standaard oplossing wil hebben voor dit probleem.

Fuck bazen. Dat hij dan zelf een oplossing maakt/zoekt voor dat probleem.

[Crazy D]

Op vrijdag 04 januari 2002 11:28 schreef whoami het volgende:
Fuck bazen. Dat hij dan zelf een oplossing maakt/zoekt voor dat probleem.

ja da's ook erg goed voor je carriere binnen dat bedrijf

Ontopic: ik weet 'm ff niet meer, 't was niet zo heel moeilijk (als je het weet ) maar ik ben 'm ff kwijt. Als er geen antwoord komt kijk ik vanavond thuis wel ff, heb daar als het goed is code staan...

[Verwijderd]

Tablock, Tablocks, HOLDLOCK, PAGLOCK, ROWLOCK, werken ook niet

[Crazy D]

Op vrijdag 04 januari 2002 12:03 schreef apottjewijd het volgende:
Tablock, Tablocks, HOLDLOCK, PAGLOCK, ROWLOCK, werken ook niet

Ik heb me er toen ook suf naar gezocht, maar kon 't toen niet vinden. Zei opeens iemand 'kijk daar eens naar' (hele andere richting dan dat ik zocht) en 't werkte meteen. Had iig iets te maken met de locktimeout property van het connection object, maar of (en zo ja wat) je nog meer moest doen weet ik niet meer uit m'n hoofd...

[Skinny]

zoiets ? Dit bespreekt specifiek MS SQL Server

Clients in so-called "n-tier" applications are typically "disconnected" from the data source. That is, the middle-tier component doesn't hold a database connection open on behalf of the client. The component opens a connection (or reuses a pooled connection), gets the data, closes the connection, and then returns the data to the client. Then, when the client wants some more data, or to update some data that it previously fetched, the component opens a new connection to fulfill the client request. In these cases, the application and component must cooperate in order to detect attempts to update stale data.
Some application programmers ignore this problem. This is especially true in applications where there's a low probability that more than one user will try to update the same record in a given time period. The attitude seems to be "Well, it probably won't happen, so let's don't waste a lot of time coding for it." Of course, this attitude is dangerous in light of Murphy's law: If it can happen, it will happen.

In this article, I'll illustrate what I mean by stale data and present a relatively simple technique that you can employ to detect an attempt to update stale data. The technique uses the SQL Server timestamp datatype.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev99/html/VB99E1.asp

[Crazy D]

Op vrijdag 04 januari 2002 12:38 schreef Skinny het volgende:
zoiets ?

Dat is (heb het niet helemaal letterlijk gelezen...) idd een mooie manier, maar wat ik bedoel, het is me een keer netjes gelukt dat je een record opent, en als iemand anders 'm wil openen (voor edit uiteraard), kreeg ie direct een error (netjes af te vangen) dat het record gelockt is.

Naja ik weet het ff niet meer Timestamp vind ik zelf op zich een mooie manier, bij het opvragen die timestamp opslaan, en bij het wegschrijven eerst de timestamp controlleren. Is denk ik ook wat veiliger dan een echte lock (alleen minder flexibel, als je met een ander programma dan het record opent voor editten, kan dat wel gewoon).

[Skinny]

With the SET LOCK_TIMEOUT option, it is possible to set the maximum amount of time that SQL Server allows a transaction to wait for the release of a blocked resource:

code:

Syntax
   SET LOCK_TIMEOUT timeout_period

'timeout_period' indicates the number of milliseconds, while a value of -1 (the default) indicates no timeout period.

http://www.devx.com/free/tips/tipview.asp?content_id=3564

Beter ?


[edit]
Ohja, je kunt beter zoeken op 'stale data'... dat levert nuttige info (denk ik) op in google/msdn etc.

[Verwijderd]

Even een heele grote dank naar jullie toe. Echt geweldig dat jullie meteen doorhebben wat ik bedoel. Het document lijkt mijn probleem helemaal door te lopen ( was waarschijnlijk niet de enige die ermee zat ). Je moet er alleen even opkomen dat ze zoiets "Stale data" noemen. Ik denk dat ik er wel uitkom zo Thnx!

[Skinny]

Op vrijdag 04 januari 2002 13:06 schreef apottjewijd het volgende:
Je moet er alleen even opkomen dat ze zoiets "Stale data" noemen.

Dat wist ik ook niet hoor, maar bij mijn eerste reply (MSDN) noemen ze dat zo

Suc6

[Verwijderd]

Shit, ik kom er toch nog niet uit! Ik heb een fout gevonden in dat document ( of ik snap het niet ). Ik heb het dan over dat deel met die timestamps. Dat voorkomt niet dat wanneer gebruiker A een record gaat bewerken, gebruikertje B het record gewoon doodleuk weg kan gooien ( wissen ). Vervolgens kan na mijn mening gebruiker A gewoon updaten en krijg je hele rare effecten waar ik geen oplossing voor heb gezien in het vermelde document ( of denk ik nou gewoon niet goed na? ).

[Verwijderd]

Ik heb een nieuwe manier bedacht waar ik graag wat meningen over wil hebben van intelligente mede- tweakers:

Client app. start op, applicatie onthoud het IP adres, en zodra men op 'Edit' klikt in de applicatie schrijf ik naar een tabel dat gebruiker ( ip adres ) dat record wil gebruiken.

Als iemand wil gaan editen of verwijderen wordt eerst gecontroleerd in de tabel of men dat wel mag.

Bij een update of cancel wordt de 'lock' verwijderd.

Bij het eindigen van de applicatie worden alle locks voor dat ip adres verwijderd.

Bij invoeren in de tabel waarbij het IP adres en het gelockte record wordt weggeschreven schrijven we ook de huidige datum / tijd weg.

Een applicatie op de server controleerd eens in de x uur / minuten of er geen hele oude records in staan ( er geen PC's zijn vastgelopen en dat de locks blijven staan ). Wanneer ze te oud zijn wist hij ze.

Als een user wil updaten, wordt eerst gekeken of hij ( zijn IP adres ) wel degene is geweest die het record ook heeft gelocked, anders heeft ie pech.

Klinkt als ik het zo opschrijf toch als een heeele mooie manier, zonder dat ik vele timestamp velden enzo hoe te maken. Wat zijn jullie meningen hierover?

[Janoz]

Let er goed op dat mensen niet hetzelfde record kunnen locken. Klinkt raar, maar als je het bijvoorbeeld met 2 queries doet (1 kijken of gelocked is, en 1 de lock zetten) kunnen er race problemen optreden.

Het zou dan kunnen voorkomen dat bijde mensen het recht hebben om de boel te editen of dat 1 iemand het id heeft dat ie kan editen (en na veel veranderingen erachter komt dat al het werk voor niks is geweest).

[Verwijderd]

Op vrijdag 04 januari 2002 13:43 schreef Gijs iets best wel slims:
Let er goed op dat mensen niet hetzelfde record kunnen locken. Klinkt raar, maar als je het bijvoorbeeld met 2 queries doet (1 kijken of gelocked is, en 1 de lock zetten) kunnen er race problemen optreden.

Het zou dan kunnen voorkomen dat bijde mensen het recht hebben om de boel te editen of dat 1 iemand het id heeft dat ie kan editen (en na veel veranderingen erachter komt dat al het werk voor niks is geweest).

Hmmmmm... dat is wel weer een erg slimme gedachte... maar ik heb er ( hopelijk ) een oplossing voor...

Om een lock naar mijn lock- tabel weg te schrijven maak ik een stored procedure in de database. Deze kan WEL gewoon table locking gebruiken, en er dus zeker van zijn dat het record alleen wordt geplaatst als ie er nog niet staat, en voor andere users die dat tussentijds willen een 'jammer' terugsturen.

Klinkt dit slim ?

[Janoz]

Ik heb het zelf een keer opgelost door met een update te werken

update locks set locked=true, ...... where locked = false and .......

en vervolgens kijken hoeveel rows zijn aangepast.

Je moet gewoon goed opletten als je met de boel bezig gaat. Belangrijkste regel waar je rekening mee moet houden is Murphy's law... Everything that can go wrong, WILL go wrong!!

[Verwijderd]

Hmmmm... is ook over nagedacht Janoz zo zou het inderdaad ook kunnen. Maar ik denk dat ik het idee zoals ik hem heb gemaakt toch eens ga proberen, kan dan namelijk ook een soort administrator maken die Altijd een "edit in progress" kan overrulen ( gooit gewoon die recordlock weg ), de niet admin- user krijgt dan netjes een melding dat ie voor niks heeft lopen updaten, en de admin zijn update heeft wel effect.

Denk dat dat met het oog op de toekomst voor dit programma wel de meeste flexibiliteit bied. Ik hoop alleen dat het gaat werken.

[Verwijderd]

Op vrijdag 04 januari 2002 13:51 schreef apottjewijd het volgende:

[..]

Hmmmmm... dat is wel weer een erg slimme gedachte... maar ik heb er ( hopelijk ) een oplossing voor...

Om een lock naar mijn lock- tabel weg te schrijven maak ik een stored procedure in de database. Deze kan WEL gewoon table locking gebruiken, en er dus zeker van zijn dat het record alleen wordt geplaatst als ie er nog niet staat, en voor andere users die dat tussentijds willen een 'jammer' terugsturen.

Klinkt dit slim ?

Ik was dit draadje aan het lezen en dit was het eerste waar ik aan d8. Klinkt niet alleen slim, het is gewoon slim!

... of overdrijf ik nu?

[Verwijderd]

Op vrijdag 04 januari 2002 14:58 schreef hvdberg het volgende:

[..]

Ik was dit draadje aan het lezen en dit was het eerste waar ik aan d8. Klinkt niet alleen slim, het is gewoon slim!

... of overdrijf ik nu?

Thnx! Ik vond het ook wel leuk bedacht alleen ik heb zo het gevoel dat ik ergens iets over het hoofd zie, alleen weet ik niet wat... en het gaat best wel wat tijd kosten om dit idee er een beetje mooi in te programmeren.

[Verwijderd]

Nog even het resultaat: Het werkt inderdaad perfect