Profesor:
Conf. Dr. Adrian Sterca [forest at cs dot ubbcluj dot ro]

Continut:
1. Calculul concurent. Exemple. Tranzactii. Modelul Pagina si Modelul Obiect pentru sisteme concurentiale. [1, capitolul 1 si 2]
2. Istorii si planificari in sisteme concurentiale. Corectitudinea planificarii. [1, capitolul 3]
3. Planificarea seriala. Planificari serial-echivalente. [1, capitolul 3]
4. Algoritmi de controlul concurentei: blocanti, neblocanti si hibrizi. [1, capitolul 4]
5. Controlul concurentei multiversiune. [1, capitolul 5]
6. Controlul concurentei in modelul obiect. [1, capitolul 6]
Bibliografie:
1. Weikum G. Vossen G. Transactional Information System: Theory, Algorithms, and Practice of Concurrency Control and Recovery. Kaufmann Morgan Publ. 2002.

Exemple de articole posibile pentru referat
Click aici pentru alegere referat si programare sustinere.
Referatele pot fi predate si in sesiunea (normala sau restante), dar cu o penalizare de 4 puncte.
Proiectele de asemenea se pot preda si in sesiune de restante, dar cu o penalizare de 4 puncte (exceptie fac proiectele simplificate care au o penalizare de 4 puncte indiferent cand sunt predate (in timpul semestrului, in sesiune normala sau in sesiune restante)).
Prezentarile de referate vor avea loc conform tabelului:
Toate prezentarile o sa aiba loc la "Catedra", adica in cladirea centrala la centrul MOS, la subsol, sala S-10.

Cerinte:
Pentru promovarea cursului, un student masterand trebuie sa realizeze urmatoarele 3 lucruri, la care trebuie sa primeasca, la fiecare, nota peste 5:

• proiect
• referat
• sa sustina examenul scris final

Nota finala este media ponderata intre cele 3 sarcini de lucru prezentate mai sus:
40% proiect + 30% referat + 30% examen scris

Referatul trebuie sa contina 4 pagini (in romana) si sa faca rezumatul unui concept (1 articol stiintific) din domeniul modelarii sistemelor concurente. Mai exact, referatul trebuie sa urmareasca una din temele:

• modelarea proceselor concurente si decrierea lor prin limbaje de programare concurente (petri nets, logici temporale etc.)
• modelarea datelor in sisteme concurente (tranzactii, sisteme tranzactionale)
• modelarea comunicarii intre procese concurente (sincrona, asincrona, isocrona etc.)

Referatul nu trebuie sa copieze efectiv sau sa traduca cuvant cu cuvant niste articole stiintifice. De asemenea articolul pt care faceti rezumat trebuie sa introduca un concept nou (e.g. algorithm, tehnica, teorie). In plus, articolul trebuie sa aiba intre 9 si 15 pagini, sa fie publicate dupa 2010, si sa nu fie "survey" (adica articole care nu introduc ceva nou ci fac rezumatul la mai multe lucruri existente). Si ultima cerinta este sa imi trimiteti articolul (in fromat pdf sau link la articol, dar prefer pdf) pe mail ca sa imi dau acordul.
Ca sa gasiti articole stiintifice despre temele de mai sus, cautati cuvintele cheie: concurrent, concurrent formalism, concurrent constraint programming, transactional, concurrent transaction, transactional systems, process calculi, process algebras, process calculus, schedulling, concurrent schedulling la una din adresele:
http://citeseerx.ist.psu.edu/
http://scholar.google.com/
http://portal.acm.org/dl.cfm (folositi un cont si o parola pe care v-o dau la curs)
http://en.wikipedia.org/wiki/Process_calculus
http://en.wikipedia.org/wiki/Concurrent_system

Sau alegeti unul dintre articolele oferite mai sus (ca exemple de articole posibile pentru referat).

Proiect - o aplicatie concurenta distribuita la alegerea studentului. Aplicatia trebuie sa respecte urmatoarele cerinte:
- sa fie distribuita, client-server sau web, pe mai multe nivele (client/web - business/middleware - date etc.).
- sa implice aspecte de concurenta la nivel de date externe manipulate (i.e. tranzactii in baze de date).
- sa foloseasca doua baze de date diferite (cel putin 3 tabele) si sa se foloseasca tranzactii distribuite - adica o tranzactie sa lucreze pe tabele din baze de date diferite. (nu este obligatoriu sa fie 2 servere distincte de baze de date, doar 2 baze de date/scheme diferite)
- sa aiba cel putin 6-8 operatii/cazuri de utilizare.
- Foarte important: Sa implementeze un sistem tranzactional la nivel aplicatie. Adica veti considera ca o tranzactie nu consta din operatii de read() si write() de pagini de memorie asa cum facem la curs ci veti considera o tranzactie ca fiind formata din operatii SQL simple (minim 3 instructiuni SQL - insert, delete, update, select) desigur, aceste operatii SQL vor opera pe tabele diferite. Trebuie sa asigurati, la nivel aplicatie, proprietatile ACID ale acestei tranzactii. Cu alte cuvinte sa se implementeze urmatoarele:

• un algoritm de planificare (i.e. algoritm de controlul concurentei) din cele discutate la curs (bazat pe blocari sau pe ordonari, timestamp-uri etc.); aplicatia sa foloseasca 2 baze de date. Cei care implementati planificare bazata pe ordonarea timestamp-urilor trebuie sa implementati obligatoriu si un mecanism de multiversionare si sa reporniti automat orice tranzactie la care planificatorul ii da abort.
• un mecanism de rollback discutat la curs (multivesiuni, rollback pentru fiecare instructiune SQL simpla etc.)
• un mecanism de commit (poate fi gandit impreuna cu cell de rollback)
• un mecanism de detectie si rezolvare a deadlock-urilor (grafuri/liste de conflicte etc.)

- Atentie:: Focus-ul aplicatiei trebuie sa cada pe implementarea sistemului tranzactional, nu pe cazuri de utilizare, intrefata web sau frameworkuri pe care le-ati folosit. Puteti folosi framework-uri care sa va usureze munca (e.g. Hibernate sau alt JPA, Spring, .NET MVC etc.), dar nu trebuie sa folositi nici un fel de suport tranzactional de la acestea.


Un mic ghid de implementare pentru un proiect despre algoritmul 2PL (2 Phase Locking) il gasiti in aceste 3 poze: poza 1, poza 2, poza 3.

Ca alternativa la proiectul mai complex descris mai sus (i.e. implementarea unui algoritm de controlul concurentei dintre cei discutati la curs), doar pentru notele 5 si 6 (deci veti avea o penalizare de 4-5 puncte) puteti face un proiect simplificat care sa respecte urmatoarele: a) aplicatia sa fie distribuita, client-server, pe mai multe nivele (client/web - business/middleware - date etc.); b) aplicatia sa foloseasca cel putin o baza de date (nu neaparat relationala); c) aplicatia sa aiba cel putin 6-8 operatii/cazuri de utilizare.

Examenul scris este un examen grila.

Slide-uri curs si documentatii