[C#] NHibernate lock record, hoe toe te passen?

[Verwijderd]

Beste (N)Hibernate experts,

Momenteel zijn wij bezig met het ontwikkelen van een applicatie waarin nhibernate wordt toegepast. We gebruiken als database server sql server 2005. Nu heb ik hierover de volgende vraag aangaande pessimistic locking.

Bij het ophalen van een object uit de database wordt momenteel in de volgende stappen uitgevoerd:

• Sessie openen op sessionFactory
• Object laden met een willekeurige lockMode (bijv. read) met Session.Get.
• Wachten op wijzigingen gebruiker (Dit is wellicht ook niet helemaal netjes, kom ik zo op terug)
• Transactie starten
• Opslaan
  • Als dat slaagt, transactie commit en sessie sluiten
  • Als dat niet slaagt, transactie rollback

Maar nu het probleem, als ik twee keer het zelfde object opvraag kan ik ze gewoon allebei aanpassen. Er wordt dus niets gelockt. Hoe kan dit, ligt dit aan een verkeerde toepassing van het locken? Wordt de locking pas toegepast op het moment dat er wordt opgeslagen? Hoe zit dat precies? Ik kan maar beperkt voorbeelden van toepassingen vinden op internet.

Dan even over "Wachten op wijzigingen gebruiker", ik heb voorbeelden gezien waarbij een apparte sessie werd gebruikt voor het ophalen van een object en een apparte sessie voor het opslaan. Kleven er bezwaren aan het open laten staan van zo'n sessie tot de gebruiker klaar is met zijn invoer?

Ik hoop dat het een beetje duidelijk is. Alvast bedankt voor de reacties.

[EfBe]

NOOIT user activity plannen na een lock. Wat als de user denkt 'ach, ik doe dit morgen ook wel' en gaat naar huis?

[Verwijderd]

EfBe schreef op vrijdag 15 juni 2007 @ 09:44:
NOOIT user activity plannen na een lock. Wat als de user denkt 'ach, ik doe dit morgen ook wel' en gaat naar huis?

Tja, maar ik wil ook niet dat twee (of meer) users tegelijk dezelfde order gaan wijzigen bijv.

[Verwijderd]

Ben even verder gegaan met testen, geen enkele lockMode geeft resultaat. Als ik de LockMode Write gebruik geeft NHibernate een Exception: Invalid lock mode for Get(). Ook heb ik geprobeerd om de lock in de transactie te plaatsen i.p.v. ervoor maar dat geeft ook geen effect.

[Varienaja]

Gebruik een <version name="version" unsaved-value="negative"/> in je mapping, en zorg voor een bijbehorend versienummer/timestamp-veldje in je datamodel.

Hibernate past dan optimistic locking toe, en dat werkt voortreffelijk.

[Verwijderd]

Varienaja schreef op vrijdag 15 juni 2007 @ 12:16:
Gebruik een <version name="version" unsaved-value="negative"/> in je mapping, en zorg voor een bijbehorend versienummer/timestamp-veldje in je datamodel.

Hibernate past dan optimistic locking toe, en dat werkt voortreffelijk.

Bedankt, dat ga ik even proberen. Echter blijft dan dat het in sommige gevallen niet genoeg is om alleen optimistic locking te gebruiken:

- gebruiker piet opent een order
- gebruiker piet voert z'n gegevens in
- gebruiker jan opent dezelfde order
- gebruiker jan voert z'n ordergegevens in
- gebruiker jan wil opslaan, maar dat mag niet, dan zijn z'n gegevens weg als piet opslaat, dus heeft of jan of piet zn gegevens voor noppie ingevoerd..

Dus eigenlijk wil je dat jan gewoon niet in de order kan zolang piet bezig is, of zie ik het verkeerd?

[MTWZZ]

Door een timestamp of versienummer in je tabellen mee te nemen kun je zien of er iets gewijzigd is.
Voorbeeld:

code:

- Record met versienr 1
- Jan opent (heeft versie 1)
- Piet opent (heeft versie 1)
- Jan wijzigt
- Piet wijzigt
- Jan slaat op:
     - Is versienr nog steeds 1
     - Ja: opslaan en versie wordt 2
- Piet slaat op:
     - Is versienr nog steeds 1
     - Nee: Jan heeft al opgeslagen

Je app moet voor piet dus controleren of het versienummer nog klopt en dan een melding tonen dat de gegevens inmiddels gewijzigd zijn.
Afhankelijk van hoe jij dit aan de gebruikers wil mededelen kun je bijvoorbeeld de nieuwe versie ophalen en laten zien wat de wijzigingen zijn.

[ Voor 11% gewijzigd door MTWZZ op 15-06-2007 12:47 ]

[EfBe]

Verwijderd schreef op vrijdag 15 juni 2007 @ 12:28:
[...]


Bedankt, dat ga ik even proberen. Echter blijft dan dat het in sommige gevallen niet genoeg is om alleen optimistic locking te gebruiken:

- gebruiker piet opent een order
- gebruiker piet voert z'n gegevens in
- gebruiker jan opent dezelfde order
- gebruiker jan voert z'n ordergegevens in
- gebruiker jan wil opslaan, maar dat mag niet, dan zijn z'n gegevens weg als piet opslaat, dus heeft of jan of piet zn gegevens voor noppie ingevoerd..

Dus eigenlijk wil je dat jan gewoon niet in de order kan zolang piet bezig is, of zie ik het verkeerd?

Dat zou idd moeten, maar dat moet je in je applicatie oplossen, niet op de database. Dus het locken van functionaliteit ipv van de data. M..a.w.: jan wil edit klikken op die order maar het systeem laat dat niet toe want de order is al in edit mode.

Elke andere methode levert hoe dan ook dangling locks op (en dat wil je niet) of het verlies van werk. Zie: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx