[alg] Algemene omgang met transacties

[Verwijderd]

Hallo,

Ik heb een applicatie waarin meerdere schermen open kunnen staan waar de gebruiker informatie in kan muteren. Elk scherm is voorzien van een OK en annuleren knop. Nu heb ik de applicatie zo opgezet dat elk scherm zijn eigen sessie heeft. Bij het opnenen van het form een transactie binnen die sessie wordt gestart en deze bij OK wordt gecommit en in alle andere situaties(close, annuleren) een rollback wordt uitgevoerd. Ik maak gebruik van Oracle middels DOA.

Deze opzet voldoet geheel niet aan de theorie dat een transactie niet lang mag openstaan. De transactie loopt immers vanaf het creeren van het scherm tot het sluiten. Kan iemand zijn mening geven over deze opzet en uit eigenervaring vertellen hoe jullie dit soort situaties oplossen?

[Verwijderd]

Volgens mij heb ik ooit geleerd dat je de verbinding met de database in multiuser apps zo kort mogelijk moet houden.
Je haalt eerst de gegevens op uit je database, laat je gebruiker die muteren, vervolgens lock je je DB, vergelijk je de eerder opgehaalde gegevens met de huidige gegevens en doet (indien nix veranderd is) vervolgens een commit. En als controle gebruikten wij een timestamp, die bij iedere mutatie veranderd.

[whoami]

Inderdaad, die opzet is niet zo goed. Een transactie moet idd zo kort mogelijk openstaan.

Ik start altijd mijn transactie pas als ik gegevens ga gaan opslaan. Op mijn form heb ik bv 2 knoppen: een OK knop en een Annuleren knop.
De enige plaats waar gegevens naar de DB weggeschreven worden, is als er op de OK knop geklikt wordt. Dan pas wordt ook de transactie gestart, de nodige wijzigingen naar de DB gepost en gecommitted (of gerollbacked als er een fout is opgetreden).
Als er op de Annuleren knop wordt geklikt, wordt de form gewoon afgesloten zonder dat de wijzigingen naar de DB gepost worden.

[OZ-Gump]

* OZ-Gump sluit zich aan bij whoami
Deze methode werkt lekker, je legt geen verbindingen die je niet gebruikt als je geen data aanpast en je connectietijd is erg kort. Ik werk al jaren zo en dat bevalt me uitstekend!

[Verwijderd]

Is het openhouden van een transactie echt zo duur? Want ik kan met deze methode aan de gebruiker garanderen dat bij het drukken op de OK knop niet ineens rare meldingen zoals constraints waar niet aan voldaan is de kop op duiken

[whoami]

Het is toch de bedoeling van een constraint om de data integer te houden. Als de ingegeven data niet correct is, dan toon je dat toch echt het best aan de gebruiker.
Je kan die errors ook dmv exception handling opvangen en zo error handling doen hoor.

[Verwijderd]

Tuurlijk. Maar het is vervelend voor die gebruiker om pas na 5 minuten tikken hier achter te komen.

[Verwijderd]

Maar........het is me duidelijk dat er andere oplossingen zijn. Maar ik hoor graag nog wat meer argumenten waarom de hierboven beschreven manier niet goed is of beprekingen gaat opleveren.

[pagani]

Hoe zit het met locking? Wat gebeurd er als een gebruiker een scherm opent, vervolgens doet een ander dat ook, ze gaan beiden wijzigen, eentje drukt op ok,l de ander op cancel? (of een andere volgorde)

[Verwijderd]

Voor elke weiziging wordt het record momenteel write-only gelokt. Andere gebruikers kunnen de "oude" data dus gewoon zien en als ze willen weizigen krijgen vóór het wijzigen een melding dat ze geen wijzigingen kunnen aanbrengen omdat het record gelocked is.

[whoami]

Verwijderd schreef op 04 juni 2003 @ 11:06:
Tuurlijk. Maar het is vervelend voor die gebruiker om pas na 5 minuten tikken hier achter te komen.

Tja, dat zijn dingen die je moet afwegen.
Als je van optimistic concurrency gebruik maakt, dan kan het ook voorkomen dat 2 gebruikers tegelijk een bepaald record wijzigen. 1 van die 2 zal zijn wijzigingen dan ook niet kunnen posten naar de DB.

[edit]
OK. Ik lees dus dat je gebruik maakt van pessimistic locking.

[ Voor 8% gewijzigd door whoami op 04-06-2003 11:23 ]

[pagani]

Verwijderd schreef op 04 June 2003 @ 11:22:
Voor elke weiziging wordt het record momenteel write-only gelokt. Andere gebruikers kunnen de "oude" data dus gewoon zien en als ze willen weizigen krijgen vóór het wijzigen een melding dat ze geen wijzigingen kunnen aanbrengen omdat het record gelocked is.

Dat is dus reteslecht. Als een gebruiker dus z'n scherm open laat staan kan niemand anders in de betreffende record werken...

Je kunt beter bij het 'ok' klikken lezen of de data nog correct is (om te bepalen of er geen lost update is), vervolgens locken en dan de gegevens wijzigen en direct unlocken...

[ Voor 18% gewijzigd door pagani op 04-06-2003 11:37 ]

[Verwijderd]

johnnyv.nl: Klopt.
Maar het heeft wel als voordeel dat als een gebruiker (even overdrijven) een uur lang in een scherm bezig is, hij/zij niet bij het wegschrijven naar database de melding krijgt dat wegschrijven niet kan omdat het record al door een andere gebruiker gemuteerd is.

[OZ-Gump]

Verwijderd schreef op 04 June 2003 @ 11:38:
Maar het heeft wel als voordeel dat als een gebruiker (even overdrijven) een uur lang in een scherm bezig is, hij/zij niet bij het wegschrijven naar database de melding krijgt dat wegschrijven niet kan omdat het record al door een andere gebruiker gemuteerd is.

Dat kopt dan ook wel weer, maar hoeveel mensen laten geen schermen openstaan als ze koffie gaan halen, de lunch gaan nuttigen of een vergadering hebben... Al met al vind ik die oplossing echt niet goed.

Je zou natuurlijk, in verband van gemuteerde gegevens bij het klikken op ok, een melding kunnen geven met de mutaties die de ander heeft gedaan, en vervolgens vragen of de update hier al dan niet overheen hoort te komen.

Verder weet ik niet wat je precies aan het maken bent, maar het lijkt me niet dagelijks voorkomen dat twee mensen dezelfde data anders willen aanpassen? Dus lijkt de OK-knop oplossing mij beter dan de ik-lock-alles-als-ik-het-scherm-pen methode.

That's just my two cents...

[Verwijderd]

Iemand met nog meer argumenten?

[Crazy D]

Lees ook http://weblogs.asp.net/fbouma/posts/7499.aspx eens door. Imho een intressant stukje