[alg] omgaan met deadlocks client/server

[Alarmnummer]

Ik vraag me af hoe jullie omgaan met deadlocks en met name op client/server omgevingen omdat je hier dus veel resources hebt, en vaak ook veel threads.

Sommige omgevingen zoals EJB zorgen voor de concurrency control voor jou, dus je hoeft zelf niet op deadlocks te letten. Sommige omgevingen die kunnen deadlocks in het systeem detecteren, dus dan kan je een client om zijn kop geven en zeggen dat hij een roll-back moet doen. Eventueel kan je ook een timer aan een operatie zetten, en als de tijd overschreden is, dan geef je de client ook op zijn kop. Dit zijn dus allemaal een beetje noodoplossingen, want je sluit niet uit dat clients op hun kop krijgen.

Je hebt verder wel de wereld aan patterns, maar ik vraag me of zo`n systeem dan niet veel te complex gaat worden om te onderhouden. Tenslotte verstaan veel developers onder concurrency control over alhet woordje synchronized voor te plakken.

Mijn vraag is dus hoe jullie omgaan met concurrency control problematiek op complexe thread omgevingen zoals bv client/server omgevingen.
ps:
met clients bedoel ik een thread.

[whoami]

Je kan zoveel mogelijk deadlocks op een DB proberen te vermijden door iedere keer de tabellen in een bepaalde volgorde aan te spreken.

Bv als je procedure A dit doet:

code:

update tabel A
insert tabel B

en je hebt een 2de procedure die ook tabel A en tabel B nodig heeft, dan zorg je er voor dat je 2de procedure ook eerst tabel A benaderd, en dan pas tabel B.
Zo dus:

code:

delete A
update B

en niet

code:

update B
delete A

[Alarmnummer]

Databases hebben geloof ik ook een time-out beveiliging op de duur van een bepaalde actie, en je krijgt als uitvoerder van die actie dan wel een foutmelding terug. Maar wat ga je dan doen? Stel dat het een gecompliceerde actie is geweest, of zelfs een gedistribueerde transactie, wat ga je dan doen? Hoe krijg je je normale resources (bv een object: KlantenList) weer in orde?

[edit]
En hoe schaalt jouw oplossing mee tov de grote van een systeem/database? Het lijkt me erg lastig om in grotere systemen (misschien meerdere servers die onafhankelijk van ontwikkeld zijn) met grote databases (100+ tabellen).

[ Voor 24% gewijzigd door Alarmnummer op 26-02-2004 11:00 ]

[justmental]

Ik werk in een Oracle omgeving waar deadlocks automatisch gedetecteerd worden en als fout geraised worden.
Threads die niet uit een gebruikers-event zijn ontstaan laat ik door dit mechanisme stuklopen met logging van de melding. Blijkt dit (te) vaak voor te komen dan zorg ik dat de afhankelijke gegevens binnen de threads in dezelfde volgorde bij de start van de functie gelocked worden. Zo wordt de deadlock voorkomen en gaan de threads die dezelfde gegevens muteren op elkaar wachten.
Overigens voorkom ik de problematiek liever door te threaden over een gemeenschappelijke as in de data zodat 2 threads nooit dezelfde data raken.

Bij user interfaces grijp ik bij locking problematiek het liefst naar een optimistische locking strategie waarbij de data pas bij het opslaan van de transactie gelocked wordt.
Indien de data inmiddels door een andere sessie aangepast is dan moet de gebruiker opnieuw de mutatie doen.

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 11:00:

En hoe ga je om met een error bij je transactie? Hoe krijg jij je systeem weer ok?

[whoami]

Alarmnummer schreef op 26 februari 2004 @ 11:02:
[...]

En hoe ga je om met een error bij je transactie? Hoe krijg jij je systeem weer ok?

Ik snap waarschijnlijk je vraag niet, maar als je een error krijgt binnen je transactie, dan rollback je die transactie ?

[justmental]

Alarmnummer schreef op 26 februari 2004 @ 11:02:
En hoe ga je om met een error bij je transactie? Hoe krijg jij je systeem weer ok?

De transactie wordt gerollbacked.
De job of message die de thread had opgestart wordt in een "opnieuw aanbieden" queue gezet en wordt zo nog max. 2x aangeboden.
Lukt dat niet dan gaat er een signaal het monitoring systeem in zodat een beheerder het probleem kan verhelpen.

[Alarmnummer]

De database die schrijft de wijziging niet weg, maar ik kan me voorstellen dat er tijdens de transactie ook interne geheugenstructuren aangepast worden. Hoe ga je hier mee om? Dit kan je namelijk niet zo makkelijk roll-backen

[P_de_B]

Het principe lijkt me heel eenvoudig, als er een deadlock geconstateerd word 1 van de transacties kiezen als 'slachtoffer' en terugdraaien. De andere comitten, de eerste nog een keer aanbieden. Eventueel kun je een prioriteit instellen dat bepaalde transacties minder snel als deadlock victim worden gekozen.

[whoami]

Alarmnummer schreef op 26 februari 2004 @ 11:10:
De database die schrijft de wijziging niet weg, maar ik kan me voorstellen dat er tijdens de transactie ook interne geheugenstructuren aangepast worden. Hoe ga je hier mee om? Dit kan je namelijk niet zo makkelijk roll-backen

Ga je er dan van uit dat je die geheugenstructuren nog gebruikt?
Als die data ook foutief is, dan kan je ze nog altijd opnieuw inladen.

[justmental]

Alarmnummer schreef op 26 februari 2004 @ 11:10:
De database die schrijft de wijziging niet weg, maar ik kan me voorstellen dat er tijdens de transactie ook interne geheugenstructuren aangepast worden. Hoe ga je hier mee om? Dit kan je namelijk niet zo makkelijk roll-backen

Deze snap ik niet helemaal
Een thread heeft zijn eigen memory gebied wat wordt opgeruimd als hij afgebroken is.
Globals die buiten de threads beschikbaar moeten zijn werk ik niet mee, als dat nodig is dan gaat het via de database.

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 11:13:
[...]
Deze snap ik niet helemaal
Een thread heeft zijn eigen memory gebied wat wordt opgeruimd als hij afgebroken is.
Globals die buiten de threads beschikbaar moeten zijn werk ik niet mee, als dat nodig is dan gaat het via de database.

Dan gebruik je de database als een transactional resource. Databases ondersteunen dit uiteraard, maar geheugenstructuren zijn veel lastiger om op die manier in te zetten. Je zou eventueel alle wijzigingen aan een geheugenstructuur binnen de transactie kunnen melden, en dan bij een rollback al die aanpassingen weer ongedaan maken. Maar ik kan me situaties voorstellen dat dit niet wenselijk is.

En verder programmeert dit met standaard talen ook erg naar, omdat het meldings-aspect je code vervuild. Bij AOP kan dit bv eenvoudig, maar AOP is nog lang geen mainstream paradigma.

[ Voor 13% gewijzigd door Alarmnummer op 26-02-2004 11:19 ]

[justmental]

Alarmnummer schreef op 26 februari 2004 @ 11:16:
En verder programmeert dit met standaard talen ook erg naar, omdat het meldings-aspect je code vervuild. Bij AOP kan dit bv eenvoudig, maar AOP is nog lang geen mainstream paradigma.

Wat bedoel je met het meldings-aspect?

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 11:33:
Wat bedoel je met het meldings-aspect?

Als het een normale geheugenstructuur is, zonder directe ondersteuning voor transacties, dan moet je alle wijzigingen aan deze structuur meenemen in je transactie. Als je transactie een rollback krijgt, moeten al die wijzigingen weer ongedaan worden gemaakt. Dat bedoel ik dus met het meldings-aspect.

Verder is dit ook geen ideale manier van werken omdat zoveel andere problemen kunnen optreden zoals dirty reads ed op die resource.

[ Voor 14% gewijzigd door Alarmnummer op 26-02-2004 11:37 ]

[justmental]

Alarmnummer schreef op 26 februari 2004 @ 11:36:
Als het een normale geheugenstructuur is, zonder directe ondersteuning voor transacties, dan moet je alle wijzigingen aan deze structuur meenemen in je transactie. Als je transactie een rollback krijgt, moeten al die wijzigingen weer ongedaan worden gemaakt. Dat bedoel ik dus met het meldings-aspect.

Verder is dit ook geen ideale manier van werken omdat zoveel andere problemen kunnen optreden zoals dirty reads ed op die resource.

Ik snap hem nog steeds niet echt, waarom zou je zo moeilijk doen met het geheugengebied van zo'n thread?
Opruimen en opnieuw beginnen zou ik zeggen.
Of heb je het over memory waar andere threads ook bij kunnen?

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 11:45:
[...]
Of heb je het over memory waar andere threads ook bij kunnen?

Dat bedoel ik idd. Lokaal geheugen kan je wel weggooien, maar het gaat dus ook om resources die ook vanuit andere transacties aan gesproken kunnen worden.

[justmental]

Alarmnummer schreef op 26 februari 2004 @ 11:49:
Dat bedoel ik idd. Lokaal geheugen kan je wel weggooien, maar het gaat dus ook om resources die ook vanuit andere transacties aan gesproken kunnen worden.

In mijn relationele/procedurele wereld heb ik die nooit nodig.
Is dat typisch iets van OO?

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 11:56:
[...]

In mijn relationele/procedurele wereld heb ik die nooit nodig.
Is dat typisch iets van OO?

Ik denk het niet.

Op het moment dat je dus 100% via echte transactional resources laat verlopen (dus geen normale geheugenstructuren deelt tussen transacties), dan is er geen wolkje aan de lucht. De transactional resources zorgen dan zelf voor het herstellen (of het niet wegschrijven) op het moment dat de transactie een rollback krijgt.

Maar op het moment dat je werkt met 'ordinaire' geheugenstructuren die je deelt tussen transacties, dan krijg je dus grote problemen omdat deze van huis geen acid properties ondersteunen.

Toch zie ik heel veel 'normale' gedeelde interne structuren bij client-server software, dus mijn vraag is of ik iets helemaal over het hoofd zie.

[ Voor 5% gewijzigd door Alarmnummer op 26-02-2004 12:06 ]

[JaQ]

justmental schreef op 26 februari 2004 @ 11:56:
[...]

In mijn relationele/procedurele wereld heb ik die nooit nodig.
Is dat typisch iets van OO?

Ik wil helemaal niemand op z'n tenen trappen en al helemaal niet generaliseren, maar dit is nou het verschil tussen iemand die vanuit databases ontwikkeld en dus zoveel mogelijk functionaliteit door de (relatief veilige, goed beheersbare, krachtige en schaalbare) database laat afhandelen enerzijds en een applicatieontwikkelaar die gewent is om zoveel mogelijk functionaliteit in een applicatie te zetten. (quick en dirty gaat dat zeker sneller, plakbandjes plakken dus)

Veel php en tegenwoordig zelfs ook jsp jongens die met mysql klooien en die ineens aan een fatsoenlijke database (zoals postgresql of oracle) mogen zitten, leggen geen relationele sleutels, geen constraints (nou heb je daar op zich al een fatsoenlijk ontwerp voor nodig..), gebruiken geen procedures en al helemaal geen triggers, omdat ze die in de gui/interface bouwen. Vaak is dit omdat er te weinig kennis is van de kracht van de database, niet omdat deze mensen slecht kunnen programmeren oid.

[Alarmnummer]

Ik vind jouw opmerking een beetje vreemd.

Ik geloof dat je pro-database developer bent en tegen de applicatie programmeur. Je beschrijft een beeld van applicatie programmeur die geloof ik gebaseerd is op contact met andere onprofessionele programmeurs en daarmee kan je geen generalisaties doen.

Verder valt niet alle logica in databases te plaatsen. Vooral als je moet werken met meerdere resources zoals bv een message-server.

[edit]
Er bestaan ook andere programmeurs dan alleen php/jsp en andere webtalen als je het nog niet wist.

[ Voor 16% gewijzigd door Alarmnummer op 26-02-2004 12:35 ]

[justmental]

Ik denk dat er een concreet voorbeeld nodig is om hier overeenstemming in te kunnen vinden.
Wat voor resources gebruik je in meerdere threads om wat voor doel te bereiken?

[Alarmnummer]

justmental schreef op 26 februari 2004 @ 12:34:
Ik denk dat er een concreet voorbeeld nodig is om hier overeenstemming in te kunnen vinden.
Wat voor resources gebruik je in meerdere threads om wat voor doel te bereiken?

Ik heb geen contreet voorbeeld. Ik ben me op dit moment weer aan het verdiepen in client server omgevingen, en ben me vooral aan het concentreren op concurrency en transactie problematiek. En daarbij probeer ik situaties te bedenken waarbij het fout kan gaan en ik post hier de vragen waar ik mee zit

[ Voor 5% gewijzigd door Alarmnummer op 26-02-2004 12:43 ]

[Bbfreak]

Er zijn toch heel veel voorbeeld van:
Producer/Consumer Problem
DiningPhilosophers

Of bedoelen jullie dit niet?

[JaQ]

Alarmnummer schreef op 26 februari 2004 @ 12:31:
Ik vind jouw opmerking een beetje vreemd.

Ik geloof dat je pro-database developer bent en tegen de applicatie programmeur. Je beschrijft een beeld van applicatie programmeur die geloof ik gebaseerd is op contact met andere onprofessionele programmeurs en daarmee kan je geen generalisaties doen.

Verder valt niet alle logica in databases te plaatsen. Vooral als je moet werken met meerdere resources zoals bv een message-server.

[edit]
Er bestaan ook andere programmeurs dan alleen php/jsp en andere webtalen als je het nog niet wist.

Ik stel het ook wat extremer dan dat ik het daadwerkelijk vind en ik wil je ook zeker niet beledigen.

Ik ben inderdaad een hoop onprofessionele programmeurs tegen gekomen die het niet helemaal snapten. Daarom riep ik ook: ik moet niet generaliseren. Helaas kom ik ook steeds meer matige database developers tegen die het ook niet helemaal snappen en dat is minimaal net zo erg als een matige applicatie programmeur, misschien zelfs nog wel erger. Mij maak je trouwens niet wijs dat jij alleen maar met zeer kundige en zwaar professionele programmeurs in aanraking bent gekomen. Het prutswerk van een ander repareren doet toch iedereen die iets langer in het "vak" rondloopt? (of heb ik nou de verkeerde job?)

Sommige logica hoort in een applicatie, maar business rules horen, wat mij betreft, per definitie in de database thuis (in een applicatie die tegen een database praat). Locica die niets met je database te maken heeft, hoort daar uiteraard ook niet thuis. Dit is wat ik bedoelde in mijn vorige opmerking. Business rules worden nogal eens ge-enforced door applicaties, vooral in kwalitatief minder goede programmatuur (wel eens naar Oracle Applications gekeken toevallig? typisch voorbeeld van hoe het niet moet) Uiteraard is dit een mening die je niet hoeft te delen.

Dit alles heeft niets met je originele vraag te maken, namelijk omgaan met deadlocking, waar je over aan het nadenken bent (als ik het goed begrijp). Ik denk dat je eerst moet bepalen in wat voor omgeving je werkt voordat je hier iets nuttigs over kan roepen. De ene database, danwel OS, gaat er heel anders mee om dan de volgende. VMS gaat heel anders met rechten en locking om dan een ander *nix smaakje en al helemaal anders dan Windows. Hetzelfde geldt voor MySQL, SQL*Server, postgresql of Oracle (om maar met een paar namen te gooien, uiteraard willekeurig gekozen). De mogelijkheden/kans die een database danwel OS je biedt om deadlocking te voorkomen zal je in je onderzoek moeten meenemen

Een veelgekozen oplossing die ik zie, is door het toekennen van een status aan een record te bepalen of een record geupdate mag worden of niet. In de praktijk denk ik niet dat deadlocking te voorkomen is, alhoewel je de kans wel kan minimaliseren. Detectie van een deadlock lijkt mij een onderwerp om verder in te verdiepen, meer dan het verkleinen van de kans op een deadlock. Dat is wel ingegeven door een time-money gedachte (volgens mij kan je sneller deadlock detectie maken, dan het door software volledig uit te sluiten, uiteraard wel weer afhankelijk van je omgeving)

[Alarmnummer]

Bbfreak schreef op 26 februari 2004 @ 13:10:
Er zijn toch heel veel voorbeeld van:
Producer/Consumer Problem
DiningPhilosophers

Of bedoelen jullie dit niet?

Dit is leuk voor kleine dingetjes, maar dit schaalt denk ik niet goed mee met honderden threads, resources en tig developers die aan het systeem werken.

En verder zijn er ook de wereld aan 'hogere' patterns voor concurrency control (opgebouwt uit bekendere patterns zoals producer consumer ed). Voor servers zou je bv kunen kijken naar de Reactor of de Proactor (posa), waarmee je veel problemen kan oplossen. Maar je kan niet uitsluiten dat het niet gebeurt, en de vraag is of een extreem goed functioneren ontwerp beter is dan een makkelijk te onderhouden ontwerp die zo nu en dan wat transacties (ten onrechte) afkeurt.

[ Voor 4% gewijzigd door Alarmnummer op 26-02-2004 14:18 ]

[Alarmnummer]

[quote]DrFrankenstoner schreef op 26 februari 2004 @ 13:13:

Mij maak je trouwens niet wijs dat jij alleen maar met zeer kundige en zwaar professionele programmeurs in aanraking bent gekomen. Het prutswerk van een ander repareren doet toch iedereen die iets langer in het "vak" rondloopt? (of heb ik nou de verkeerde job?)

Er heeft een lange tijd 'prutser-hunter' bij mijn sig gestaan Ik kom ze dus vaak genoeg tegen maar ik heb de hoop dat er ook goeie developers zijn

Sommige logica hoort in een applicatie, maar business rules horen, wat mij betreft,
per definitie in de database thuis (in een applicatie die tegen een database praat).

Business logic hoort per definitie niet thuis in een database, maar zelfs ook niet binnen een applicatie. Business logic moet volledig buiten de applicatie en database worden getrokken, zodat het inzichtelijk en aanpasbaar is voor de managers. En verder is het ook erg naar dat je de developers moet vragen om aanpassingen te maken (dit is niet altijd mogelijk, vooral als het bedrijf failiet is). Business logic wordt (als het goed is) ondergebracht in rule-engines.

Uiteraard is dit een mening die je niet hoeft te delen.

Principles of the Business Rule Approach
Business Rules Applied: Building Better Systems Using the Business Rules Approach

Om maar een paar boeken te noemen die alleen maar gaan over het externaliseren van de business rules.

De ene database, danwel OS, gaat er heel anders mee om dan de volgende. VMS gaat heel anders met rechten en locking om dan een ander *nix smaakje en al helemaal anders dan Windows. Hetzelfde geldt voor MySQL, SQL*Server, postgresql of Oracle (om maar met een paar namen te gooien, uiteraard willekeurig gekozen). De mogelijkheden/kans die een database danwel OS je biedt om deadlocking te voorkomen zal je in je onderzoek moeten meenemen

Meestal is er wel een gemeenschappelijke draad en ik die probeer ik op te pakken. Uiteraard heeft iedere database,os ed altijd zijn eigen haken en ogen.

Dat is wel ingegeven door een time-money gedachte (volgens mij kan je sneller deadlock detectie maken, dan het door software volledig uit te sluiten, uiteraard wel weer afhankelijk van je omgeving)

Idd.