TDP024. Informationssökning Datalayer JPA - Facade, Logging, Testing. Enterprise Systems. Anders Fröberg Institutionen för Datavetenskap (IDA)

Transkript

1 TDP024 Enterprise Systems Informationssökning Datalayer JPA - Facade, Logging, Testing Anders Fröberg Institutionen för Datavetenskap (IDA) 1

2 Agenda Skrivuppgiften Programming to an interface JPA 2

3 TDP024 IN A NUTSHELL I examensordningen står det att för alla kandidatexamina skall bland andra följande mål uppnås: (Även andra examina än kandidatexamina har nästan identiska mål) 1.visa förmåga att söka, samla, värdera och kritiskt tolka relevant information i en problemställning samt att kritiskt diskutera företeelser, frågeställningar och situationer 2.visa sådan färdighet som fordras för att självständigt arbeta inom det område som utbildningen avser 3.visa förmåga att självständigt identifiera, formulera och lösa problem samt att genomföra uppgifter inom givna tidsramar 4.visa förmåga att muntligt och skriftligt redogöra för och diskutera information, problem och lösningar i dialog med olika grupper 3 3

4 TDP024 Informationssökning Visa förmåga att söka, samla, värdera och kritiskt tolka relevant information i en problemställning samt att kritiskt diskutera företeelser, frågeställningar och situationer Individuell rapport och seminarier 1Hp Sök och välj ut tre bra forskningsartiklarna relaterade till kursens innehåll. Skriv en sammanfattning och analys av alla tre artiklarna på en A4-sida vardera. Värdera varje artikel - Varför är den bra 4 4

5 Uppgift Individuell rapport och seminarie 1Hp Denna uppgift går ut på att genomföra en fördjupning i aktuell forskning inom kursens områden samt träna på att utvärdera vetenskaplig litteratur. Samt diskutera innehållet av de ni läst på ett seminarie med de andra studenterna. Sök och välj ut tre bra forskningsartiklarna relaterade till kursens innehåll. Skriv en sammanfattning och analys av alla tre artiklarna på en A4-sida vardera. Som språk kan antingen svenska eller engelska använda. Sammanfattningen/analysen ska utförligt besvara följande frågor: Vad är artikelns syfte? Hur har det presenterade arbetet lagts upp (tillvägagångssätt/metod)? Vilka resultat kommer artikeln fram till? Vad finns det för begränsningar i arbetet? Avsluta varje analys med att redogöra varför artikel är en bra artikel. 5

6 Hitta

7 Vad gör en artikel bra? Vem Hur många artiklar Erkänd inom området Var Tidskrift eller Konferensbidrag (ev Workshop) Ranking och Impact Factor ( isi_listed_se_journals.html) Vilka andra Hur många andra har citerat artikeln 7

8 TDP024 Enterprise Systems Program to an Interface och Dependency Injection Anders Fröberg Institutionen för Datavetenskap (IDA)

9 Program to an interface Program to an interface är en metod att organisera och bygga sitt system på som är grundläggande för alla system som skall vara modulära och hållbara. För en programmerare är det bland de viktigaste kunskaper man kan ta med sig in i ett projekt. Projekt som väljer enklare metoder, eller hittar genvägar runt, har en drastiskt förkortad livslängd. Det är på abstraktionsnivån programmering som denna metod befinner sig, inte på samma abstraktionsnivå som SCRUM eller arkitektur, etc. 9 2

10 Program to an interface I den här kursen är det omöjligt att klara laborationerna utan att ha förståelse för program to an interface. Eventuella avvikelser från metoden i laborationerna kommer ge komplettering. I arbetslivet är det en självklarhet att man har denna kunskap med sig, och deltar man i ett projekt som inte använder sig av program to an interface ska man kämpa för att de börjar med det. 10 3

11 Program to an interface I den korthet: här kursen är det omöjligt att klara laborationerna Systemet man bygger utan att skall ha förståelse knytas samman för program och bero to på an interface. kontrakt mellan olika delar. Eventuella Det skall inte avvikelser bero på från en viss metoden implementation. i laborationerna kommer ge komplettering. T ex. ett system skall vara beroende på sorterar en lista, inte på bubble sort. I Att arbetslivet sortera en är det lista en är ett självklarhet kontrakt, jag att säger man till har ett denna annat system kunskap sortera med sig, denna och deltar lista och man får i ett tillbaka projekt en som inte sorterad använder lista. Det sig av spelar program dock inte mig to an någon interface roll hur ska detta man gick kämpa till, jag för har att skrivit de börjar kod som med jobbar det. mot kontraktet inte mot en viss implementation av kontraktet

12 Program to an interface public interface Sort { List sort(list list); public class BubbleSort implements Sort { public List sort(list list) { //Do bubble sort När jag skriver kod så jobbar jag mot interfacet, jag vet att alla klasser som uppfyller kontraktet kommer ha en funktion som heter sort och tar en lista och returnerar en lista. public class QuickSort implements Sort { public List sort(list list) { //Do quick sort 12 5

13 Program to an interface public interface Sort { List sort(list list); När någon sedan kommer fram till en snabbare sorteringsalgoritm så behöver jag inte ändra i min kod, för den är skriven mot ett kontrakt, inte mot en implementation. public class BubbleSort implements Sort { public List sort(list list) { //Do bubble sort public class QuickSort implements Sort { public List sort(list list) { //Do quick sort public class QuantSort implements Sort { public List sort(list list) { //Do quick sort 13 6

14 Program to an interface public class ListUtils { private Sort sort; Interface, det står inte: private BubbleSort sort; public List findsmallest(list list) { list = sort.sort(list); return list.get(0); Använder en metod som jag vet finns enligt kontraktet, oavsett vilken implementation jag använder. That s a null pointer exception! 14 7

15 Dependency Injection public class ListUtils { private Sort sort; public ListUtils(Sort sort) { this.sort = sort; ListUtils väljer inte vilken implementation den skall använda. I sin konstruktor så accepterar den en instans av en implementation. (Notera att vi fortfarande endast använder interfaces). public List findsmallest(list list) { list = sort.sort(list); return list.get(0); Detta kallar vi dependency injection det består alltså av en klass som har en instansvariabel som blir satt i konstruktorn. 15 8

16 Dependency Injection public static void main(string [] args) { ListUtil listutil = new ListUtil(new QuickSort()); int min = listutil.findsmallest([21,13,55,34]) Någon gång måste man välja implementation, i detta fall är det koden som skapar ett nytt objekt av ListUtil som måste välja vilken implementation som skall användas. För den intresserade så går det även att få bort detta beroende. Med hjälp av Inversion of Control kan man få program to an interface on steroids. Du anger aldrig vilken implementation som skall användas i koden, utan detta löses runtime från t ex en XML fil som säger vilken implementation av Sort som skall användas just nu. 9 Vi har inte tid med Inversion of Control i denna kurs, men det rekommenderas till den intresserade. 16

17 Program to an interface Enhetstestning drar också stora fördelar från att fokusera på kontrakt snarare än implementation. Test the contract, not the implementation Om vi skriver våra test mot kontrakt så kan vi testa oändligt många implementationer av samma kontrakt. Om någon kommer och påstår att de har en ny implementation som är bättre, så kan man testa implementationen mot redan existerande tester

18 Program to an interface public class Test { //--- Unit under test ---// private Sort sort = new BubbleSort(); // // Koden i testet är oberoende av implementationen. Innan vi kör testet kan vi byta implementation. public void test() { List a = [4,3,5,2,6]; List b = sort.sort(a); Assert.assertTrue(b[0] == 2); Om någon kommer och påstår att de har en bättre implementation, så tar vi deras kod och instansierar deras lösning istället. Testen är exakt desamma

19 Data Logic - Web Logik Data och Logik teamen sitter tillsammans och kommer överens om ett API (dvs ett kontrakt) för vilka funktioner som kommer behövas från datalagret. Som en del av detta arbete så skrivs också alla tester, dvs alla tester som måste vara uppfyllda för att logik teamet skall känna sig trygga i att använda data lagret. Data API Tests 19 12

20 Data Logic - Web Logik Data API API Tests Tests Data teamet tar sin kopia av kontrakt och tester och börjar sedan implementera. De är helt oberoende av alla andra delar av projektet. Och resten av projektet är helt oberoende av deras implementationsdetaljer

21 Logik Data Logic - Web Web API Data Tests API Tests Web och logik teamen gör precis samma sak. De kommer överens om ett kontrakt för kommunikation mellan web och logiklagret. I denna process skrivs även tester. API Tests 21 14

22 Data Logic - Web API Data Logik Tests Web API Tests API Tests Data Nu har logik lagret ett kontrakt som de vet kommer bli uppfyllt (samt tester). Och de har ett kontrakt som de skall uppfylla (samt tester)

23 Web Data Logic - Web API Data API Tests Tests Logik 16 Logiklagret kan skriva all sin kod så att den uppfyller kontraktet mot web. Eftersom logiklagret ALLTID jobbar mot kontraktet så behöver man inte vänta på en implementation från datalagret. API Tests Men hur kan man testa sin logik utan att kunna skapa instanser av de kontrakt som data lagret ska leverera? Måste man vänta på att data lagret blir klara? 23 Data

24 Web Data Logic - Web API Data API Tests Tests Logik API Tests Data Just fake it! Logik lagret har ju kontrakten från data lagret, de kan skapa sitt egna lilla fejk datalager som de kan använda för att testa med. 17 Detta kallas ofta mocking eller creating mock objects 24

25 Mock objects - Mocking public class Test { //--- Unit under test ---// private Sort sort = new Sort() { public List sort(list sort) { return [2]; // // public void test() { List a = [4,3,5,2,6]; List b = sort.sort(a); Assert.assertTrue(b[0] == 2); Så vi skapar en egen implementation av Sort (till dess att data lagret är klara med sin) som vi kan testa med. Den behöver inte vara bra, så länge den gör vad den ska. När data lagret sedan är klara så stoppar vi in deras implementation istället

26 Data Logic - Web Web Logik Data Web implementation API Tests Logic implementation API Tests DB implementation När alla delar är på plats så har man ett system som är modulärt och hållbart. De olika implementationerna är endast beroende på kontrakten

27 Data Logic - Web Web Logik Data Web implementation API Tests Logic implementation API Tests DB implementation Om datalagret får för sig att byta sin implementation till t ex. ett system som sparar i en molntjänst istället för på lokal databas, eller vill helt plötsligt börja spara i flat-files, så spelar det ingen roll för de andra. Så länge datalagret lovar att upprätthålla kontraktet och testerna så behöver ingen ändra sin kod. Cloud implementation 27 20

28 Data Logic - Web Även inom data lagret är det smidig att testa nya implementationer (eftersom de redan har tester). Data Antag att ett av biblioteken som data lagret använder uppdateras från 1.0 till 2.0, och mycket har ändrats i den nya versionen. Istället för att börja ändra i sin existerande implementation så skapar man en ny, som är helt baserad på 2.0, men testerna är de samma. När man väl är färdig med implementationen (och den passerar alla tester) så kan man byta ut den gamla utan att någon behöver ändra på sin kod. API Tests DB 1.0 implementation DB 2.0 implementation 28 21

29 Summering av Föreläsning 1 Vi tittade på HSV s examensmål, och fick en överblick av kursdesignen utifrån dessa. Vi definierade: Multi-Tier, SOA, Enterprise Systems, program to an interface och dependency injection. Vi tittade på våra SOA principer: Contract, Abstraction, Autonomy och Stateless Vi tittade på kursens fokus på arkitektur, och tog med oss Bezos kommentar: 2 All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 29

30 Backend SOA Tjänst Egentligen flera lager Backend DB, DATA, LOGIC, EXPOSURE (WEB) MySQL. MongoDB, LDAP, etc DB DATA$ SOA$ TJänster LOGIC$ EXPOSURE$(WEB)$ 3 Klienter kan vara webbsidor, desktop/mobil applikationer, andra SOA tjänster, ATM, parkeringsautomater etc.. Konsument Konsument 30

31 Motivation & Problem Sparande och förmedling av information är det centrala i våra tjänster Databaser gör det möjligt för oss att spara information på ett säkert och stabilt sätt Data bör komma in och ut ur applikationen på ett naturligt sätt En SQL databas är en samling tabeller med rader och kolumner En Java applikation består utav objekt JPA är ett Java bibliotek (del utav Java EE) som översätter Java klasser till rader och kolumner - ORM (Objekt-Relational-Mapping) 4 31

32 JPA POJO Instanser av klasser annoterade kan sparas till används för att konfigurera kolumnen för ett fält (nullable, unique, etc) Som ett minimum behöver man annotera ett fält för primary-key Egentligen är klassen en POJO (Pure Old Java Objekt) utan några speciella krafter JPA kommer skapa tabeller som anses nödvändiga Kan hantera komplexa relationer mellan klasser och även datatyper så som HashMap och List (med lite konfiguration) 32 5

33 JPA - Entity Exempel Interface public interface Todo { public class TodoDB implements Todo { long getid(); void setid(long id); String private long id; private String title; private String body; void settitle(string public long getid() { return id;

34 JPA Table Example id$6$bigint(20)$ =tle$6$varchar(255)$ content$6$varchar(255)$ 1" Title"1" Content"1" 2" Title"2" Content"2" 3" Title"3" Content"3" " " " " " " Behöver inte fundera på vilka tabeller eller kolumner som bör skapas, detta görs åt mig. Innebär att det är lättare att byta databas den dagen företaget väljer att köpa in t ex Oracle, eller helt byta till t ex MongoDB (som inte består utav rader och kolumner alls) 7 34

35 EntityManager & Transactions Förutom att använda annotations på klasser som skall sparas i databasen så behöver vi kommunicera med databasen. En EntityManager skapas genom klassen EntityManagerFactory EntityManager ansvarar för att skapa, starta och avsluta transactions All kommunikation som skriver till databasen måste ske inom en transaktion Antingen så lyckas alla operationer inom en transaktion eller så misslyckas alla 35 8

36 Transactions Transaktionen öppnar vid t0, och under tiden den är öppen görs ett antal skrivningar till databasen. Så länge allt fungerar som det ska, så skrivs allt data till databasen och vi kommer till t1, där transaktionen stängs Om något går fel inom transaktionen, så görs först en rollback på alla operationer, och transaktionen stängs. Allt är som det var vid t

37 Glöm inte bort EntityManager," En0tyManagerFactory"och"Transac0ons,"vi" återkommer"0ll"dessa"strax! Ett design pattern är ett namn på en konstruktion eller uppsättning klasser som jobbar tillsammans på ett sätt som är användbart för många applikationer. Det ger utvecklare ett vokabulär att kommunicera med istället för att upprepa sig själva hela tiden. Intermezzo FAÇADE DESIGN PATTERN 10 37

38 Intermezzo Façade Design Pattern Har jag glömt något? 38 11

39 Klart! Intermezzo Façade Design Pattern 39 12

40 Intermezzo - Facade Design Pattern En klass vars uppgift det är att abstrahera komplexa delar, och på så vis förenkla interaktionen med systemet I datalagret använder vi façades för att erbjuda funktioner för verben create, remove, update, find Det är viktigt att tänka på att de façades som vi skapar i datalagret skall hantera generiska verb som är lika mellan applikationer, inte saker som är unika för just din tjänst. Vi har även façades i logiklagret som kan hantera andra typer av verb, så som checkin och checkout mer om detta på senare föreläsningar 13 40

41 JPA Façade, EMF, Transactions public class TodoEntityFacadeDB implements TodoEntityFacade public long create(string title, String body) { EntityManager em = EMF.createEntityManager(); em.gettransaction().begin(); Todo todo = new TodoDB(); todo.settitle(title); todo.setbody(body); em.persist(todo); em.gettransaction().commit(); EMF är en klass som man måste skapa själv, det finns en sådan i kodskelettet. Exemplet är inte komplett då vi inte hanterar eventuella fel på ett bra sätt. Mer om detta senare. return todo.getid(); 14 Interface på vänstersidan, implementation på höger! 41

42 JPA - Konfiguration JPA behöver konfigureras för att veta vilka klasser som skall sparas JPA behöver information om var databasen är och hur vi kopplar oss mot den En grundläggande persistence.xml finns i kodskelettet. /src/meta-inf/ persistence.xml src/main/resources/ persistence.xml Vi kommer använda en databas som bara existerar i RAM, så inga ändringar behövs för detta. Finns en hel del andra inställningar som är viktiga, t ex drop-and-create 42 15

43 persistence.xml Lägg till en sådan rad för varje entity. <persistence-unit name="todo-datapu" transaction-type="resource_local"> <provider>org.eclipse.persistence.jpa.persistenceprovider</provider> <class>tdp024.todo.data.db.entity.tododb</class> <shared-cache-mode>none</shared-cache-mode> <validation-mode>none</validation-mode> <properties> <property name="javax.persistence.jdbc.url value="jdbc:derby:memory:datapu_embedded;create= <property name="javax.persistence.jdbc.password" value=""/> <property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.embeddeddriver"/ <property name="javax.persistence.jdbc.user" value=""/> <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/> </properties> </persistence-unit></persistence> 16 43

44 Motivation & Problem Hur vet man att façaden är klar och kan användas av logiklagret? Om man ändrar i sin façade i efterhand, hur vet man att något inte gått sönder? Hur vet man att det inte finns några buggar i sin façade? 44 17

45 JPA - JUnit 18 Viktigt att enhetstesta sin façade med Junit Test your interface, not your implementation Under utvecklingen skriver man först test för de funktioner man tror sin façade kommer behöva, sedan skriver man själva funktionerna När alla testen kör så vet man att façaden är klar och fungerar Test Driven Development (TDD) är en del av extreme Programming De viktigaste fördelarna är: Systemet är testat och fungerar som tänkt. Endast de funktioner man behöver har utvecklats, dvs lösningen är inte overengineered. Det går snabbt att kontrollera att ändringar i systemet inte har ändrat funktionaliteten (recession testing) 45

46 JPA - TDD Realizing quality improvement through test driven development: results and experiences of four industrial teams - Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams - (2008) (From abstract of paper) Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15 35% increase in initial development time after adopting TDD

47 JPA JUnit public void test() { TodoFacade todofacade = new TodoFacade(); long id = todofacade.create( Todo 1, Don t forget ); Assert.assertFalse(id == 0); Inte ett komplett exempel, men sådana finns i kodskelet och i föreläsnings kod. Det fina med att skriva testfall på detta sätt är att man kan få ut rapporter på hur många av sina test som gått igenom och att man kan få code-coverage

48 Motivation & Problem 48 21

49 JPA Find & JPQL Vi vill kunna hämta enskilda objekt ur databasen Vi vill hitta dessa via valfri column, t ex id eller title Vi vill också kunna hämta alla objekt tillhörande en klass, eller en filtrerad lista JQPL har ett SQL liknande syntax Skapa ett Query objekt genom EntityManager Sätt parametrar i Query objekt Hämta ett objekt eller en lista 49 22

50 JPA Find & JPQL - Exempel Find by id (@Id) public Todo find(long id) { EntityManager em = EMF.createEntityManager(); Todo todo = em.find(tododb.class, id); return todo; Interface Letar efter en implementation Vi skriver inte till databasen, så vi behöver ingen transaction 50 23

51 JPA Find & JPQL - Exempel Find by title public Todo findbytitle(string title) { EntityManager em = EMF.createEntityManager(); Query query = em.createquery( SELECT t FROM TodoDB t WHERE t.title = :titleparam ); query.setparameter( titleparam, title); return (Todo) query.getsingleresult(); Vi skriver inte till databasen, så vi behöver ingen transaction. Exemplet är inte komplett då vi inte hanterar eventuella fel

52 JPA Find & JPQL - Exempel Find all public List<Todo> findall() { EntityManager em = EMF.createEntityManager(); Query query = em.createquery( SELECT t FROM TodoDB t ); return query.getresultlist(); Vi skriver inte till databasen, så vi behöver ingen transaction. Exemplet är inte komplett då vi inte hanterar eventuella fel

53 Motivation & Problem Anything that can go wrong will go wrong - Murphy s Law Data -> Databas (Nätverk, inkorrekt data, etc) Databas -> Data (Nätverk) Jordbävning i serverhall? Strömavbrott? Moth in relay? 53 26

54 JPA - Exceptions Ibland avbryts exekveringen pga ett fel Servrar kan vara nere, nätverk kan vara otillgängliga Ett logiskt fel, t ex samma för flera konton Att bara hantera felet tyst, utan att tala om att något har gått fel är oftast inte så användbart Vi vill tala om för anropet att något gått fel, men inte krascha systemet Viktigt att hantera olika typer av fel på olika sätt 54 27

55 JPA Exceptions - Exempel public class TodoEntityFacadeDB implements TodoEntityFacade { public long create(string title, String body) throws Exception { if(title == null title.isempty()) { throw new IllegalArgumentException( Title can t be null or empty ); 55 28

56 Återblick Façade, EMF, Transactions public class TodoEntityFacadeDB implements TodoEntityFacade { public long create(string title, String body) { EntityManager em = EMF.createEntityManager(); em.gettransaction().begin(); Todo todo = new TodoDB(); todo.settitle(title); todo.setbody(body); em.persist(todo); em.gettransaction().commit(); return todo.getid(); 56 29

57 JPA Exceptions - Exempel samma kod som tidigare exempel EntityManager em = EMF.createEntityManager(); try { //samma kod som i tidigare men vi stänger inte EntityManager. catch (Exception e) { gör något med felet return 0; finally { if(em.gettransaction().isactive()) { em.gettransaction().rollback(); em.close(); Returnera$0,$då$vet$användaren$a5$ objektet$inte$har$sparats$i$databasen$och$ a5$något$gå5$fel.$ $ finally $körs$allfd,$oavse5$om$fel$har$ uppstå5$eller$inte,$det$ger$oss$möjlighet$ a5$göra$rollbacks$på$transakfonen$och$ stänga$vår$enftymanager$innan$vi$gör$ något$annat.$ $ Vi$F5ar$på$de5a$i$e5$tydligare$exempel$ senare $ 57 30

58 JPA - Logging Att logga alla anrop och fel gör att det blir enklare att hitta buggar när systemet väl är igång Genom att skriva till något persistent, istället för bara System.out, så kan vi gå tillbaka i tiden och även visualisera med HTML eller annat format Loggning kan också ske i form av mejl Men det finns ett problem med den modell vi visat här Vad händer om vår tjänst ligger bakom en loadbalancer och är skalad till 20 servrar? Alla anrop hamnar på olika servrar, så då har vi 20 filer som alla har loggat delar av en användares väg genom systemet 58 31

59 Motivation & Problem 59 32

60 Distribuerad Loggning Istället bör man komplettera sin vanliga loggning med distribuerad loggning Monlog är utvecklat vid Linköpings Universitet av IP studenter under VT2012 T ex en tjänst som tar emot loggmeddelanden och ordnar dessa centralt Uppgifter om hur man använder Monlog finns i laborations beskrivningen Vi använder Monlog för detta Användarnamn, lösenord och API nycklar skickas av kursledningen via mejl 60 33

61 Motivation & Problem 61 34

62 JPA - Mappings id$6$bigint(20)$ =tle$6$varchar(255)$ content$6$varchar(255)$ 1" Title"1" Content"1" 2" Title"2" Content"2" 3" Title"3" Content"3" " " " " " " Vår första Entity skapade en tabell som ovan, den innehåll bara strängar och heltal 62 35

63 Motivation & Problem 63 36

64 JPA - Mappings Komplexa förbindelser, Todo Väldigt viktigt med utförliga testfall för att förstå hur dessa mappings påverkar varandra och databasens uppbyggnad Det finns många inställningsmöjligheter med mappings, och det är ofta viktigt att testa en inställning, titta på hur databasen skapas för detta och ta ett beslut om man vill använda den strukturen Skriv testfall som testar vad som händer om man tar bort, lägger till, uppdaterar objekten i en relation 37 64

65 JPA Mappings exempel public class TodoDB implements Todo { public class CategoryDB implements private long id; private long id; private String title; private String username; private String private Category category, targetentity= TodoDB.class) private List<Todo> todos; 38 65

66 39 66

67 JPA - Concurrency Våra tjänster har inte bara en tråd Räkna med att för varje ny användare skapas en ny tråd, och då ofta en ny EntityManager Vad händer om man försöker köra samma funktion samtidigt, t ex uppdatera en Todo? Pessimistisk: Lås hela raden som skall ändras, ingen annan för röra den tills tråden är klar, lås upp när vi är klara Optimistisk: Hämta objekt och ändra som vanligt, men om objektet har ändrats i databasen när vi försöker skriva så fallerar funktionen 67 40

68 JPA Concurrency Exempel public long update(long id, String title, String body) { Todo todo = em.find(tododb.class, id, LockModeType.PESSIMISTIC_WRITE); För andra varianter av LockModeType kolla länkar under kurslitteratur på hemsidan 41 68

69 JPA Concurrency Klassiskt exempel (OBS: Pseudo kod) function debit(amount) { Account account = findaccount(); if(account.credit >= amount) { account.credit = account.credit amount; persisttodatabase(account); return true; else { return false; Antag att Account bara har 100kr på sitt konto, och vi får in två requests samtidigt med en debitering på 100kr 42 69

70 JPA Concurrency Klassiskt exempel (OBS: Pseudo kod) Tråd 2 väntar. function debit(amount) { Account account = findaccount(); if(account.credit >= amount) { account.credit = account.credit amount; persisttodatabase(account); return true; else { return false; Tråd 1 Antag att Account bara har 100kr på sitt konto, och vi får in två requests samtidigt med en debitering på 100kr 70 43

71 JPA Concurrency Klassiskt exempel (OBS: Pseudo kod) function debit(amount) { CPU n har valt att arbeta med tråd 2, tråd 1 står därmed still. Account account = findaccount(); if(account.credit >= amount) { account.credit = account.credit amount; persisttodatabase(account); return true; else { return false; Tråd 1 Tråd 2 Tråd 2 debiterar och skriver till, databasen. Account har nu 0kr på sitt konto. Antag att Account bara har 100kr på sitt konto, och vi får in två requests samtidigt med en debitering på 100kr 71 44

72 JPA Concurrency Klassiskt exempel (OBS: Pseudo kod) function debit(amount) { Account account = findaccount(); Tråd 2 är klar Tråd 1 har redan kollat att account hade >= 100kr, så den kör på. if(account.credit >= amount) { account.credit = account.credit amount; persisttodatabase(account); return true; else { return false; Tråd 1 När Tråd 1 är klar har vi debiterat, 200 kr från account (som bara hade 100kr) och account.credit == 0 Antag att Account bara har 100kr på sitt konto, och vi får in två requests samtidigt med en debitering på 100kr 45 72

73 46 73

74 JPA - Validering Det finns bibliotek som del av Java EE som löser detta problem. Man kan automatiskt validera , siffor, max o min, godtyckliga strängar etc. Biblioteket kallas Bean Validation. Vi kommer inte att ta på oss problemet med validering i denna kurs, men det är naturligtvis ett viktigt problem i större system

75 Datalayer - DONE DB Problem som hanteras Entity Mapping Validation Del av datalagret Facade JUnit Transaction Query TDD Concurrency Exception Recession Code-Coverage 75 48

76 76