Section 5: Le parall

1
Le parallélisme

• le parallélisme
• les accès concurrents
• le verrouillage des données
• Les cadenas
• Chapitre 12 du manuel de référence

2
Le parallélisme en Java

• Gérer via les fils dexécution
•  threads 
• Un fil dexécution est un traitement indépendant
• Utilisé quand un autre traitement puet se faire
  dans les temps morts
• Accès disque
• Réflexion de lutilisateur
• Délai réseau

3
Exemple
class ThreadDemo extends Thread private String
name public ThreadDemo(String name) this.name
name public void run() int count
100 while (countgt0) count-- ..
Thread.sleep(100) System.out.println(Thread
name) ..
4
Démarrer un fil dexécution
ThreadDemo thA new ThreadDemo(Thread
A) ThreadDemo thB new ThreadDemo(Thread
B) ThreadDemo thC new ThreadDemo(Thread
C) thA.start() thB.start() thC.start()
5
Objets partagés

• Quand 2 Threads travaillent en même temps sur les
  mêmes données
• interfèrent lune avec lautre
• Résultent en des données inconsistentes
• Plusieurs solutions

6
Synchronised

• Un seul fil dexécution à la fois
• Un seul fil a la main dans un objet synchronisé

7
Utiliser synchronised (i)
class IntTest private int value public
IntTest(int value) this.value
value public synchronized void
increment() value
8
Utiliser synchronised(ii)
public synchronized void decrement() value-

9
Autre solution

• Wait et Notify
• Wait
• Relâcher lexécution
• Donner la main à un autre fil dexécution
• Notify
• Informer au moins un Thread que des conditions ou
  des variables globales ont changées

10
Le parallélisme distribué

• Dans un système client-serveur, les clients
  accèdent en parallèle aux données centrales
• Habituellement, ces données sont conservées dans
  un système de base données plutôt que dans la
  mémoire
• Doù le besoin de gestion de la concurrence

11
Modèles de gestion de la concurrence

• Basé sur le concept des cadenas de lecture
  et/décriture
• Plusieurs lecteurs/un seul écrivain à la fois

12
Cadenas/lecture/écriture
Type de Cadenas Cadenas en lecture demandé Cadenas en écriture demandé
aucun Permis Permis
Lecture Permis Attendre
Écriture Attendre Attendre
13
Logique daffaire

• Une transaction daffaire peut lire et modifier
  plusieurs enregistrements
• Dans une même table
• Dans plusieurs tables
• Dans plusieurs bases de données sur un même
  serveur
• Sur plusieurs serveurs de base de données

14
Le graphe de létreinte fatale
T1 attend T3
T1
T3
T2
15
Plusieurs niveaux de cadenas

• Enregistrement
• Page
• Table
• Base de données au complet

16
Diverses stratégie du cadenas

• Les SGBD permettent plusieurs formes de gestion
  des cadenas de la base de données
• Cela permet de troquer
• Performance
• versus
• Moment dexécution de laccès concurrent

17
Trois problèmes

• Lecture sale (dirty reads)
• A transaction reads data written by concurrent
  uncommitted transaction.
• Lecture non-rejouable (non-repeatable reads)
• A transaction re-reads data it has previously
  read and finds that data has been modified by
  another transaction (that committed since the
  initial read).
• Lecture fantome ( phantom read )
• A transaction re-executes a query returning a set
  of rows that satisfy a search condition and finds
  that the set of rows satisfying the condition has
  changed due to another recently-committed
  transaction.

18
Quatre grande stratégie disolation

• 4 niveaux disolation définis par le standard SQL
• Read uncommited
• Lire les données, même les données modifiées en
  cours de transactions
• Read commited
• Ne lire que les données commises
• Read repeatable
• Proche du Cursor Stability (CS)
• Lensemble des données lues sont cadenassées
  jusquà ce que la transaction atteigne un
   commit 
• Une relecture dans une même transaction donne
  exactement les mêmes résultats
• Serializable
• Sérialise lexécution des transactions
• Lensemble des tables accédées par une
  transaction sont cadenasées

19
Isolation Level Dirty Read Non-Repeatable Read Phantom Read
Read uncommitted Possible Possible Possible
Read committed Not Possible Possible Possible
Repeteable read Not Possible Not Possible Possible
Serializable Not Possible Not Possible Not Possible
20
Les transactions

• - Chapitre 13 du manuel de référence

21
Une transaction typique

• Un client commande un item
• Le système vérifie que litem est disponible
• Si litem est disponible, alors litem est
  affecté à ce client et le total ditems
  disponible est décrémenté de un.
• Si le total de litem est bas, alors placer une
  commande pour recommander cet item

22
Un exemple de transaction

• Commander de nouveau chèque.
• Simple!
• Regardez1. the database for the account
  management website has to be updated (system
  web). usually the database is not the accounting
  database.2. an entry must be made in the
  electronic fund transfer database (system eft). 1
  for withdrawing money from customer account, 1
  for transfer to checking processing company, 1
  for service charge to the bank3. an entry must
  be made in the accounting database (system M)4.
  an entry must be made in the transaction
  validation database (system DW)5. an entry must
  be made in the data warehousing database6. a
  call to the check processing system (system CP)
  must be made. if the system is down, the
  transaction has to be saved and processed in a
  batch later.7. a entry must be made for the
  customers account info in system CP8. an entry
  must be made for a new order in system CP9. the
  order number returned by system CP must be saved
  to system Web, EFT and M.

23
Une transaction

• I'll be even more specific with the scenario. How
  would you solve this problem.1. 5 different
  systems. some are not in your control2. each
  transaction requires multiple insert/updates to
  each system3. a transaction must not be
  committed, if the transaction log fails. ie, an
  insert to the transaction log database fails.
  therefore, if 3 inserts are performed with the
  same connection, you can't just rollback all
  three. 4. some database tables have triggers,
  which rely on data in other tables. therefore,
  some inserts are dependent on other inserts and
  sequence is critical5. the transaction has to
  finish within 30 seconds6. the systems are
  remote7. the commit threshold depends on the
  context of each transaction, and therefore varies
  significantly.

24
ACID

• Propriétés désirées dune transaction
• Atomicity, Consistency, Isolation et Durability
• Atomique, Consistant, Isolé et Durable
• Atomique
• Une transaction doit être atomique, faite au
  complet ou aucunement faite
• Consistente
• Une transaction doit en tout temps laisser les
  données persistantes dans un état cohérent, par
  exemple une transaction de débit-crédit
• Isolation
• Une transaction ne doit pas être affectée par les
  autres transactions
• Durable
• Après la transaction, ses effets sont permanents
  et durables dans la base de données

25
Niveaux de complexité

• Élémentaire
• transaction sur une table
• Sur une base de donnée
• Plusieurs tables
• Sur un serveur applicatif, J2EE
• Avec les composants J2EE daffaires
• Des sous-systèmes de communications asynchrones
  JMS
• Sur plusieurs systèmes

26
Ressources

• Gourmandes en ressources
• Connexions BD
• Lock
• Etc
• Temps

27
Transactions

• Courtes
• Rapide
• Synchrone
• Sous le contrôle du système
• Longues
• Interventions externes
• Asynchrones
• Avec un système de communications asynchrones
• Longues en temps

28
Transactions distribués

• Utiles pour 2 raisons
• Elles permettent plus de concurrence entre des
  systèmes différents
• Elles permettent plus de flexibilités dans les
  politiques dannulation des transactions

29
Protocole dengagement en 2 phases

• Two phase commit protocols
• Protocole standard pour maintenir les propriétés
  ACID
• Gère quant une transaction doit être annulée ou
  poursuivie
• Basé sur le vote
• Peut être utilisé pour les transactions imbriquées

30

• Début de transaction pour tous
• Modifications aux données sur les différents
  systèmes
• Fin du travail
• Vote-Veto (Go/Nogo)
• Retour arrière ou fin transaction

31
Règles de contrôle dans les transactions
imbriquées

• Les transactions parentes ne peuvent pas
  sexécuter en même temps que les transactions
  enfants
• Les enfants vont hériter des cadenas de leur
  parent
• Si une transaction imbriquée veut un cadenas de
  lecture, alors il est accordé seulement si les
  détenteurs des cadenas décriture sont des
  ancêtres
• Si une transaction imbriquée veut un cadenas
  décriture, alors il est accordé seulement si les
  détenteurs des cadenas sont des ancêtres

32
Règles de contrôle dans les transactions
imbriquées

• Quand une transaction fait le commit, alors tous
  les cadenas sont transmis à son parent
• Quand une transaction termine abruptement, alors
  tous ses cadenas sont enlevés

33
Étreinte fatale distribuée

• Quand il y a une contention sur une ressource
  commune au travers dun système distribué
• Prendre un serveur central pour résoudre les
  étreinte fatale nest pas pratique
• Les meilleurs modèles de solutions se font en
  passant des messages sur le réseau

34
An edge chasing algorithm (i)
When a server detects that a transaction T1 has
started waiting for another transaction T2 it
sends an item of data T1 ? T2, known as a probe,
to the server which contains the data item which
is blocking T2. If there are a number of
transactions sharing the lock then the probe is
also sent to them.
35
An edge chasing algorithm (ii)
When a server receives a probe T1 ? T2 it checks
whether T2 is waiting for another transaction,
say T3. If it is then the probe is augmented to
be T1 ? T2 ? T3 and if T3 is waiting it is
forwarded on to the server which holds the data
that it is waiting for.
36
An edge chasing algorithm (iii)
When a server receives a probe and attempts to
augment it, it will check for cycles. For
example if a probe is T1 ? T2 ? T3 ? T4 and an
attempt is made to augment the probe with T2 to
form T1 ? T2 ? T3 ? T4 ? T2 and form a cycle
then a potential deadlock can be detected. When
the deadlock is detected one of the transactions
in the probe is aborted.
37
Les moniteurs transactionnels

• Logiciels qui mettent en place les propriétés
  ACID des transactions
• Gère aussi le contrôle du parallélisme des
  transactions
• Ont été développé depuis lépoque des ordinateurs
  centraux
• Cachent aux programmeurs plein de détails pointus

38
CICS, un exemple

• IBM
• Démarre, gère et termine les fils dexécution
• Gère les ressources matérielles et logicielles
• Récupère les transactions qui échouent
• Partage la charge de travail entre plusieurs
  ressources
• Gère les disfonctionnements, autant matériel que
  logiciel

39
Java Transaction Architecture - JTA

• Standard Java pour les appels à un service de
  gestion de transaction
• Habituellement fait automatiquement par les
  appels SQL ou les EJB
• Peut être programmé manuellement
• Une grande diversité dimplémentations
• Référence
• http//www.developer.com/java/ent/article.php/2224
  921
• http//www.theserverside.com/resources/article.jsp
  ?lNuts-and-Bolts-of-Transaction-Processing
• http//java.sun.com/products/jta