Oefenquiz week 3 Concurrency, Optimistic Locking in Spring JDBC

Deze oefenquiz is gebaseerd op de FilmFestival-vraag over concurrency.

Klassendiagram

PlantUML broncode voor "Klassendiagram FilmFestival Concurrency"

@startuml
rectangle "Aggregate Dagplanning" {
  class Dagplanning <<AR>> {
    id: Integer
    voegToe(onderdeel: Onderdeel)
  }

  class Onderdeel <<Value Object>> {
    vertoningId: Integer
    starttijd: Time
    eindtijd: Time
  }
}

Dagplanning "1" --> "onderdelen *" Onderdeel
@enduml

Klassendiagram met 2 klasse(n) en 1 relatie(s).

Klassen:

• Klasse Dagplanning met stereotype AR met:
  • publieke methode 'voegToe', met parameter(s) 'onderdeel' van type Onderdeel, return type void
  • publieke attribuut 'id' van type Integer
• Klasse Onderdeel met stereotype Value Object met:
  • publieke attribuut 'vertoningId' van type Integer
  • publieke attribuut 'starttijd' van type Time
  • publieke attribuut 'eindtijd' van type Time
  • geen methoden

Relaties:

• Dagplanning heeft een associatie-relatie met naam 'onderdelen *' met Onderdeel

Voor scenario A, B en C geldt: er is geen optimistic locking (@Version) geimplementeerd.

Waarom kunnen twee gebruikers tegelijk dezelfde dagplanning aanpassen?

• In deze (fictieve) app kan een dagplanning gedeeld zijn met een vriendengroep.
• Ook kan een festivalmedewerker namens een bezoeker wijzigingen doen bij hulp aan de balie.
• En het kan dat dezelfde gebruiker nog een tweede tab open heeft met dezelfde dagplanning.

Scenario A

PlantUML broncode voor "Scenario A"

@startuml
autonumber
actor Bezoeker1
participant controller1 as "dagplanningController:DagplanningController"
participant d1 as "dagplanning:Dagplanning"
participant o1 as "onderdeel:Onderdeel"
database repo as "dagplanningRepository"
participant o2 as "onderdeel:Onderdeel"
participant d2 as "dagplanning:Dagplanning"
participant controller2 as "dagplanningController:DagplanningController"
actor Bezoeker2

Bezoeker1 -> controller1: POST dagplanningen/1/onderdelen (vertoningId: 11)
controller1 -> o1 ** : onderdeel = new Onderdeel(11, 10:00, 12:00)

Bezoeker2 -> controller2: POST dagplanningen/1/onderdelen (vertoningId: 22)
controller2 -> o2 ** : onderdeel = new Onderdeel(22, 14:00, 16:00)

controller2 -> repo: dagplanning = findById(1)
controller2 -> d2: voegToe(onderdeel)

controller1 -> repo: dagplanning = findById(1)
controller1 -> d1: voegToe(onderdeel)
controller1 -> repo: save(dagplanning)

controller2 -> repo: save(dagplanning)
@enduml

Sequentiediagram met 11 deelnemers: Bezoeker1, "dagplanningController van het type DagplanningController", "dagplanning van het type Dagplanning", "onderdeel van het type Onderdeel", "onderdeel van het type Onderdeel", "dagplanning van het type Dagplanning", "dagplanningController van het type DagplanningController", Bezoeker2, o1 **, o2 ** en repo.

Interacties:

1. Bezoeker1 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 11) aan
2. "dagplanningController roept o1 **.onderdeel = new Onderdeel(11, 10:00, 12:00) aan
3. Bezoeker2 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 22) aan
4. "dagplanningController roept o2 **.onderdeel = new Onderdeel(22, 14:00, 16:00) aan
5. "dagplanningController roept repo.dagplanning = findById(1) aan
6. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
7. "dagplanningController roept repo.dagplanning = findById(1) aan
8. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
9. "dagplanningController roept repo.save(dagplanning) aan
10. "dagplanningController roept repo.save(dagplanning) aan

i

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

Scenario A: Welke data zit er in de database nadat het sequentiediagram helemaal is doorlopen?

Alleen onderdeel met vertoningId 11, omdat Bezoeker 1 eerder savetBeide nieuwe onderdelen, omdat Spring Boot Data JDBC twee save-calls automatisch samenvoegtGeen van beide, omdat de tweede save de eerste transactie terugdraaitAlleen vertoning 22; de laatste save overschrijft (hier) de vorige

Scenario B

PlantUML broncode voor "Scenario B"

@startuml
autonumber
actor Bezoeker1
participant controller1 as "dagplanningController:DagplanningController"
participant d1 as "dagplanning:Dagplanning"
participant o1 as "onderdeel:Onderdeel"
database repo as "dagplanningRepository"
participant o2 as "onderdeel:Onderdeel"
participant d2 as "dagplanning:Dagplanning"
participant controller2 as "dagplanningController:DagplanningController"
actor Bezoeker2

Bezoeker1 -> controller1: POST dagplanningen/1/onderdelen (vertoningId: 11)
controller1 -> o1 ** : onderdeel = new Onderdeel(11, 10:00, 12:00)
controller1 -> repo: dagplanning = findById(1)

Bezoeker2 -> controller2: POST dagplanningen/1/onderdelen (vertoningId: 22)
controller2 -> o2 ** : onderdeel = new Onderdeel(22, 14:00, 16:00)

controller2 -> repo: dagplanning = findById(1)
controller2 -> d2: voegToe(onderdeel)
controller2 -> repo: save(dagplanning)

controller1 -> d1: voegToe(onderdeel)
controller1 -> repo: save(dagplanning)
@enduml

Sequentiediagram met 11 deelnemers: Bezoeker1, "dagplanningController van het type DagplanningController", "dagplanning van het type Dagplanning", "onderdeel van het type Onderdeel", "onderdeel van het type Onderdeel", "dagplanning van het type Dagplanning", "dagplanningController van het type DagplanningController", Bezoeker2, o1 **, repo en o2 **.

Interacties:

1. Bezoeker1 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 11) aan
2. "dagplanningController roept o1 **.onderdeel = new Onderdeel(11, 10:00, 12:00) aan
3. "dagplanningController roept repo.dagplanning = findById(1) aan
4. Bezoeker2 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 22) aan
5. "dagplanningController roept o2 **.onderdeel = new Onderdeel(22, 14:00, 16:00) aan
6. "dagplanningController roept repo.dagplanning = findById(1) aan
7. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
8. "dagplanningController roept repo.save(dagplanning) aan
9. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
10. "dagplanningController roept repo.save(dagplanning) aan

i

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

Scenario B: Welke data zit er in de database nadat het sequentiediagram helemaal is doorlopen?

Alleen onderdeel met vertoningId 22, omdat de Gebruiker deze als eerste savetBeide nieuwe onderdelen, omdat de tweede save de eerdere staat altijd aanvultAlleen onderdeel met vertoningId 11, omdat controller1 als laatste savetGeen van beide onderdelen, omdat concurrerende writes elkaar opheffen

Scenario C

PlantUML broncode voor "Scenario C"

@startuml
autonumber
actor Bezoeker1
participant controller1 as "dagplanningController:DagplanningController"
participant d1 as "dagplanning:Dagplanning"
participant o1 as "onderdeel:Onderdeel"
database repo as "dagplanningRepository"
participant o2 as "onderdeel:Onderdeel"
participant d2 as "dagplanning:Dagplanning"
participant controller2 as "dagplanningController:DagplanningController"
actor Bezoeker2

Bezoeker1 -> controller1: POST dagplanningen/1/onderdelen (vertoningId: 11)
controller1 -> o1 ** : onderdeel = new Onderdeel(11, 10:00, 12:00)

Bezoeker2 -> controller2: POST dagplanningen/1/onderdelen (vertoningId: 22)
controller2 -> o2 ** : onderdeel = new Onderdeel(22, 14:00, 16:00)

controller1 -> repo: dagplanning = findById(1)
controller1 -> d1: voegToe(onderdeel)
controller1 -> repo: save(dagplanning)

controller2 -> repo: dagplanning = findById(1)
controller2 -> d2: voegToe(onderdeel)
controller2 -> repo: save(dagplanning)
@enduml

Sequentiediagram met 11 deelnemers: Bezoeker1, "dagplanningController van het type DagplanningController", "dagplanning van het type Dagplanning", "onderdeel van het type Onderdeel", "onderdeel van het type Onderdeel", "dagplanning van het type Dagplanning", "dagplanningController van het type DagplanningController", Bezoeker2, o1 **, o2 ** en repo.

Interacties:

1. Bezoeker1 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 11) aan
2. "dagplanningController roept o1 **.onderdeel = new Onderdeel(11, 10:00, 12:00) aan
3. Bezoeker2 roept "dagplanningController.POST dagplanningen/1/onderdelen (vertoningId: 22) aan
4. "dagplanningController roept o2 **.onderdeel = new Onderdeel(22, 14:00, 16:00) aan
5. "dagplanningController roept repo.dagplanning = findById(1) aan
6. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
7. "dagplanningController roept repo.save(dagplanning) aan
8. "dagplanningController roept repo.dagplanning = findById(1) aan
9. "dagplanningController roept "dagplanning.voegToe(onderdeel) aan
10. "dagplanningController roept repo.save(dagplanning) aan

i

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

Scenario C: Welke data zit er in de database nadat het sequentiediagram helemaal is doorlopen?

Alleen onderdeel met vertoningId 11, omdat controller1 als eerste de complete flow doorlooptGeen van beide, omdat parallelle requests zonder @Version niet opgeslagen wordenBeide nieuwe onderdelen, omdat controller2 pas leest nadat controller1 al heeft opgeslagenAlleen onderdeel met vertoningId 22, omdat de laatste save altijd alles van controller1 overschrijft

Verdiepingsvragen over volgorde en locking

i

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

Welke stap markeert het begin van de sectie waarin lost updates kunnen ontstaan?

new Onderdeel(...), omdat daar de mutatie van het domeinobject ontstaatHTTP POST van de gebruiker, omdat vanaf dat moment twee requests tegelijk bestaanfindById(...) / findInStore(...) op de repository, omdat daar met een specifieke ingelezen versie gewerkt gaat wordenvoegToe(...), omdat het aggregate daar intern de lijst wijzigt

Wat betekent 'concurrency' in deze lescontext het best?

Dat teamleden concurreren om wie de code als eerste mergedDat requests strikt na elkaar lopen, zodat volgorde nooit uitmaaktDat acties van meerdere gebruikers door elkaar heen kunnen lopen in de tijd (*interleaving*)Dat de database automatisch gelijktijdige wijzigingen samenvoegt via (optimistic of pessimistic) locking

Welke stap markeert het einde van die sectie?

findById(...), omdat daarna alle domeinlogica en invarianten al bekend zijnnew Onderdeel(...), omdat daarna alleen nog persistence volgtvoegToe(...), omdat de wijziging dan al in geheugen is doorgevoerdsave(...) op de repository, omdat die de ingelezen versie definitief opslaat

In scenario B: als je alleen de twee save-stappen omdraait (controller1 save eerst, controller2 save daarna), wat is dan het resultaat?

Alleen onderdeel met vertoningId 22 staat in de databaseBeide nieuwe onderdelen staan in de databaseAlleen onderdeel met vertoningId 11 staat in de databaseEr komt altijd automatisch een optimistic-lock exception

Welke annotatie gebruik je voor optimistic locking in JPA?

@Id@Version@LockGeen annotatie, want Spring Data doet dit altijd impliciet

Stel: optimistic locking is goed geimplementeerd. Wat gebeurt er bij twee concurrerende updates op hetzelfde record?

De laatste save wint altijd, hetzelfde gedrag als zonder lockingBeide saves worden samengevoegd zolang de gewijzigde velden verschillenDe tweede conflicterende save faalt; de eerste succesvolle save bepaalt de uiteindelijke dataDegene die als eerste findById doet, bepaalt de uiteindelijke data

Wat is typisch voor het gedrag zonder optimistic locking in deze scenario’s?

Er treedt altijd direct een exception op, dus foutieve data komt niet voorDe eerste save wint per definitie, daardoor is gedrag voorspelbaarConcurrency heeft nauwelijks effect, want save() is standaard atomair over requests heenJe krijgt vaak stille, tijdelijke of terugkerende dataproblemen zonder foutmelding (lost updates)