[postgresql] transacties over meerdere html requests

[hobbit_be]

hoi

voor een admin die door x-aantal mensen kan worden gebruikt zou ik graag transacties gebruiken om ervoor te zorgen dat ze niet in elkaar's vaarwater terechtkomen.

de admin is html / ajax based.

voorlopig zitten der geen transacties in vooral omdat ik niet zeker bent hoe je transacties over verschilldende requests doet:

ie.

stel dat de user begint met de admin op web request 1 (begin transaction, safepoint) dan doet ie misschien wel 30 / 40 queries voor allerlei kleine aanpassingen totdat ie beslist te saven -> commit.

maar aangezien de transactie in een andere connectie begint lijkt me dit dus niet mogelijk ->

vraag is dus hoe kan ik ervoor zorgen (door session managment) dat ik de BEGIN and COMMIT 1 2 verschillende requests kan doen (mijn backend is PHP5.0, maar de vraag is universeel).

Bestaat er zoiets als een transactie-id die ik dan opnieuw can opstarten?

ie:

request 1:
transactie-id = new Transactie
bewaar transactie-id
begin transactie
--- hoop queries....


request 2:
resume transactie transactie-id
----
Commit.

Of iets daarmee logisch overeen komt.

heb een boel gegoogled maar ken vast niet de juiste benaming.

Ideetjes?

[JKVA]

Persoonlijk zou ik kijken naar iets als optimistic locking. Dat is iets dat onder andere in Hibernate (Java ORM) gebruikt wordt.

Optimistic locking maakt gebruik van een version attribuut in je entity en checkt op dat version attribuut bij elke wijziging die je naar de database stuurt. Op deze manier heb je geen dure (pessimistic) locks op je database, maar kun je toch lost updates tegengaan.

http://www.hibernate.org/...en/html/transactions.html

[RobIII]

Een transactie over meerdere requests is IMHO sowieso geen goed idee. Maak een 'workqueue' aan, 'queue' daar wat je te doen staat en op het moment dat je klaar bent (laatste request) flush je je que met een nieuwe transactie, verwerken van de items, transactie committen danwel rollbacken.

[hobbit_be]

jkva - ik heb over die optimistic locking wat verder gekeken en eigenlijk moet ik dan van alle objecten die ik gebruik locaal opslaan (in een session) var zodat de update failt als iemand anders der aan is gekomen. Blijkbaar de norm zoals je aanhaalt in EJB en Hibernate.

rob3 - daar heeft ons team idd voor gekozen maar dit involved veel werk omdat je dan eigenlijk terwijle het editen gebeurt ook een locale kopie moet doen (ik denk dat .NET ook zo een mechanisme gebruikt).

maar SQL heeft dus niet zo een mechanisme voor de 'lazy' - let the database take care of it - aanpak? Dit is eigenlijk een probleem van de stateless-heid van html. een andere oplossing zou kunnen zijn dat je een persistant connectie gebruikt of een connection pool waarvan je der een paar kunt 'garanderen' dat de klant steeds dezelfde krijgt (met een timeout die dar ook gerespecteerd wordt in html).

Eigenlijk is dit een probleem dat toch vaak moet voorkomen bijvoorbeeld in boeking's site van luchtvaart maatschappijen waarop je pas op het eind te horen krijgt dat jouw reservatie al weg is.

[twiekert]

hobbit_be schreef op zondag 10 februari 2008 @ 14:26:
hoi

voor een admin die door x-aantal mensen kan worden gebruikt zou ik graag transacties gebruiken om ervoor te zorgen dat ze niet in elkaar's vaarwater terechtkomen.

de admin is html / ajax based.

Transactions an sich voorkomen niet dat mensen elkaars data gaan overschrijven. Het garandeert alleen dat een transactie als geheel wordt uitgevoerd en dat de data die wordt aangepast in die transactie pas zichtbaar is voor andere transacties als deze gecommit is.

Als je data wilt beschermen tegen concurrent updates (bijv dat persoon A data binnenhaalt en aanpast en dat daar tussenin persoon B de data ook heeft gewijzigd, persoon A baseert zijn wijzigingen dus op de data die op het scherm staat terwijl deze door B al zijn aangepast)

dan moet moet je gebruik maken van optimistic (version) of pessimistic (row/table locks etc) locking