4.1 Transaksjoner og databaseintegritet

Den normale driftsmodusen til en database er når den mottar tusenvis av forespørsler hvert minutt fra hundrevis av forskjellige klienter. I dette tilfellet oppstår ofte situasjoner når de samme dataene får tilgang fra forskjellige spørringer.

Sjeldnere, men igjen, fra tid til annen er det situasjoner når en forespørsel leser en bestemt linje, og en annen forespørsel endrer den samtidig. Tenk deg hva som skjer hvis noen leser en linje som bare er halvveis endret? Ikke noe bra.

Dette problemet løses på flere måter. Først kan du bare låse linjen som endres. Både til lesing og skriving. Denne metoden fungerer, men hastigheten på basen lider sterkt.

Den andre måten er å låse strengen for kun å skrive. Det vil imidlertid fortsatt være et problem når noen prøver å lese den delvis modifiserte linjen. Konklusjon - det bør ikke være en situasjon når linjen er delvis endret.

Derfor kom de opp med en tredje metode - transaksjoner. En transaksjon er en gruppe handlinger som utføres enten alle sammen eller ingen i det hele tatt. Det kan ikke være en situasjon der en del av handlingene ble utført, og den andre delen ikke ble det. Hvis det ikke er mulig å gjøre alle endringene, rulles alle endringene som allerede er gjort tilbake.

Enhver moderne SQL-server lar deg endre data bare i transaksjoner. Du åpner en transaksjon, gjør endringer i et hvilket som helst antall tabeller og forplikter transaksjonen. SQL Server prøver deretter å gjøre endringer. Hvis alt er bra, vil de bli lagt til den generelle databasen. Hvis det var problemer, vil alle endringer bli kansellert.

Hibernate bruker også dette paradigmet. Det er derfor vi i forrige forelesning så at når man forsøkte å lagre Employee-objektet til databasen, ble en transaksjon først åpnet, og etter lagring ble den forpliktet.

Vi vil gå inn på dette emnet mer detaljert, men for nå, bare vet hvorfor transaksjoner er nødvendig og hvor de vanligvis brukes.

4.2 Få gjenstander

Hvis Hibernate utfører en forespørsel om å få data, er det ikke nødvendig å eksplisitt åpne en transaksjon. Hibernate selv vil gjøre dette hvis den finner det passende: den har sine innstillinger, så vel som innstillingene til SQL-serveren.

Vi vil analysere hvordan man jobber med databasen. Og den enkleste av dem er å få et objekt etter ID- en . For å gjøre dette, bruk metoden get()sesjonsobjektet . Den generelle formen for en slik forespørsel:

Class Name = session.get(Class.class, ID);

Eksempel:

public User getUserById(Integer id) {
    try (Session session = sessionFactory.openSession()) {
        User user = session.get(User.class, id);
        return user;
    }
}

4.3 Lagre (legge til) objekter

Hvis du vil lagre objektet ditt i databasen, vil en spørring bli utført på SQL-nivåSETT INN. Derfor må handlingene dine utføres som en separat transaksjon. Det er også bedre å bruke sesjonsobjektetspersist() metode for persistens .

Den generelle formen for en slik forespørsel:

session.persist(An object);

Metoden persist()endrer ikke bare basen, men også selve objektet. Saken er at når vi legger til et objekt i databasen, har ikke dette objektet sin egen ID før det legges til . Vel, vanligvis det, selv om det er nyanser. Og etter å ha lagt til har objektet allerede en ID .

public boolean saveUser(User user) {
    try (Session session = sessionFactory.openSession()) {
            Transaction transaction = session.beginTransaction();
            session.persist(user);
            transaction.commit();
            return true;
    }
    catch() {
    return false;
   	}
}

Session- objektet har også en metode save()som utfører en lignende funksjon. Det er bare det at metoden save()er den gamle Hibernate-standarden og metoden persist()er JPA-standarden.

4.4 Slette objekter

Hvis du ønsker å slette et eksisterende objekt, så er det veldig enkelt å gjøre det. For å gjøre dette har sesjonsobjektet en spesiell metode - remove().

Den generelle formen for en slik forespørsel:

session.remove(An object);

Og la oss selvfølgelig skrive koden med et eksempel:

public boolean removeUser(User user) {
    try (Session session = sessionFactory.openSession()) {
            Transaction transaction = session.beginTransaction();
            session.remove(user);
            transaction.commit();
            return true;
    }
    catch() {
    return false;
   	}
}

Hvorfor er det så vanskelig, spør du?

Vel, for det første har alle endringer i databasen alltid forskjellige og ikke alltid åpenbare konsekvenser. Og for det andre kan dette objektet ha underordnede objekter knyttet til seg, osv. Så slettingsscenarier er ofte ikke-trivielle.