1. CS551 - Lecture 18 1 CS551 Object Oriented Middleware (VII) Advanced Topics (Chap. 10-12 of EDO) Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc.edu www.cstp.umkc.edu/~yugi

2. 2 CS551 - Lecture 18 Distributed Object Transaction (Chap 10) What happens if a failure occurs during modification of resources? Which operations have been completed or not (and have to be done again)? In which states will the resources be? –Atomicity: either performed completely or no modification, Start of a transaction/End of transaction –Consistency: Shared resources should always be consistent: Transactions can be aborted if they cannot resolve them –Isolation: Each transaction accesses resources as if there were no other concurrent transactions. –Durability:A completed transaction is always persistent What happens if a failure occurs during modification of resources? Which operations have been completed or not (and have to be done again)? In which states will the resources be? –Atomicity: either performed completely or no modification, Start of a transaction/End of transaction –Consistency: Shared resources should always be consistent: Transactions can be aborted if they cannot resolve them –Isolation: Each transaction accesses resources as if there were no other concurrent transactions. –Durability:A completed transaction is always persistent

3. 3 CS551 - Lecture 18 Transaction Commands Begin: –Start a new transaction. Commit: –End a transaction. –Store changes made during transaction. –Make changes accessible to other transactions. Abort: –End a transaction. –Undo all changes made during the transaction. Begin: –Start a new transaction. Commit: –End a transaction. –Store changes made during transaction. –Make changes accessible to other transactions. Abort: –End a transaction. –Undo all changes made during the transaction.

4. 4 CS551 - Lecture 18 Flat Transaction Begin Trans. Cras h Flat Transaction AbortBegin Trans. Flat Transactions CommitBegin Trans. Flat Transaction

5. 5 CS551 - Lecture 18 Central vs. Distributed Transactions Transactions in a Database –Centralized –DBMS controls transaction execution –DBMS implements concurrency control –Transaction processing transparent to application developers Problem occurs if: –Data kept in different databases or –Distributed objects do not use a database –Transaction processing not transparent to application developers Transactions in a Database –Centralized –DBMS controls transaction execution –DBMS implements concurrency control –Transaction processing transparent to application developers Problem occurs if: –Data kept in different databases or –Distributed objects do not use a database –Transaction processing not transparent to application developers

6. 6 CS551 - Lecture 18 Concurrency Control (Chap 11) Components of distributed systems use shared resources concurrently: –Hardware Components, Operating system resources, Databases, Objects Resources may have to be accessed in mutual exclusion. Concurrent access and updates of resources may lead to –lost updates (e.g. Cash withdrawal from ATM and concurren) –inconsistent analysis (e.g. Funds transfer between accounts of a customer) Components of distributed systems use shared resources concurrently: –Hardware Components, Operating system resources, Databases, Objects Resources may have to be accessed in mutual exclusion. Concurrent access and updates of resources may lead to –lost updates (e.g. Cash withdrawal from ATM and concurren) –inconsistent analysis (e.g. Funds transfer between accounts of a customer)

7. 7 CS551 - Lecture 18 Two Phase Locking (2PL) The most popular concurrency control technique. –RDBMSs (Oracle, Ingres, Sybase, DB/2, etc.) –ODBMSs (O2, ObjectStore, Versant, etc.) –Transaction Monitors (CICS, etc) Concurrent processes acquire locks on shared resources from lock manager. –A lock is a token that indicates that a process accesses a resource in a particular mode (read and write). –Locks are used to indicate to concurrent processes the current use of that resource. –Guarantees serialisability The most popular concurrency control technique. –RDBMSs (Oracle, Ingres, Sybase, DB/2, etc.) –ODBMSs (O2, ObjectStore, Versant, etc.) –Transaction Monitors (CICS, etc) Concurrent processes acquire locks on shared resources from lock manager. –A lock is a token that indicates that a process accesses a resource in a particular mode (read and write). –Locks are used to indicate to concurrent processes the current use of that resource. –Guarantees serialisability

8. 8 CS551 - Lecture 18 Lock Compatibility/Conflict Lock manager –Grants locks depending on compatibility of acquisition request with modes of already granted locks. –Compatibility defined in lock compatibility matrix. Locking conflict –Lock requests cannot be granted if incompatible locks are held by concurrent processes –To handle conflicts: Force requesting process to wait until conflicting locks released Tell process or thread that lock cannot be granted. Lock manager –Grants locks depending on compatibility of acquisition request with modes of already granted locks. –Compatibility defined in lock compatibility matrix. Locking conflict –Lock requests cannot be granted if incompatible locks are held by concurrent processes –To handle conflicts: Force requesting process to wait until conflicting locks released Tell process or thread that lock cannot be granted.

9. 9 CS551 - Lecture 18 Deadlocks 2PL may lead to processes waiting for each other to release locks. Deadlocks have to be detected by the lock manager. Deadlocks have to be resolved by aborting one or several of the processes involved. –This requires to undo all the actions that these processes have done. –Abort Transactions that consumed least processor time/with most dependencies Trade-off between degree of concurrency and locking overhead. Hierarchical locking as a compromise. 2PL may lead to processes waiting for each other to release locks. Deadlocks have to be detected by the lock manager. Deadlocks have to be resolved by aborting one or several of the processes involved. –This requires to undo all the actions that these processes have done. –Abort Transactions that consumed least processor time/with most dependencies Trade-off between degree of concurrency and locking overhead. Hierarchical locking as a compromise.

10. 10 CS551 - Lecture 18 Transparency of Locking Who is acquiring locks? –Concurrency control infrastructure –Implementation of components –Clients of components First option desireable but not always possible: –Infrastructure must manage all resources –Infrastructure must know all resource accesses. Last option is undesirable and avoidable! Who is acquiring locks? –Concurrency control infrastructure –Implementation of components –Clients of components First option desireable but not always possible: –Infrastructure must manage all resources –Infrastructure must know all resource accesses. Last option is undesirable and avoidable!

11. 11 CS551 - Lecture 18 Two-Phase Commit Protocol Distributed system components involved in transactions can take role of: –Transactional Client –Transactional Server –Coordinator Two phases are needed: –Phase one: Voting –Phase two: Completion. Distributed system components involved in transactions can take role of: –Transactional Client –Transactional Server –Coordinator Two phases are needed: –Phase one: Voting –Phase two: Completion.

12. 12 CS551 - Lecture 18 Security (Chap 12) Security Attacks Encryption Higher-level Security Services –Firewalls –Authentication –Access Control –Non-Repudiation –Security Auditing Security Services in Object-Oriented Middleware Security Attacks Encryption Higher-level Security Services –Firewalls –Authentication –Access Control –Non-Repudiation –Security Auditing Security Services in Object-Oriented Middleware

13. 13 CS551 - Lecture 18 Motivation: Security Attack More vital/secret data handled by distributed components. Security: protecting data stored in and transferred between distributed components from unauthorised access. Security is a non-functional requirement that cannot be added as a component but has to be built into all components. More vital/secret data handled by distributed components. Security: protecting data stored in and transferred between distributed components from unauthorised access. Security is a non-functional requirement that cannot be added as a component but has to be built into all components.

14. 14 CS551 - Lecture 18 Why are Distributed Systems Insecure? Distributed components rely on messages sent and received from network Public Networks are insecure! Is client component secure? Is client component who it claims to be? Are users of calling components really who they claim to be? Distributed components rely on messages sent and received from network Public Networks are insecure! Is client component secure? Is client component who it claims to be? Are users of calling components really who they claim to be?

15. 15 CS551 - Lecture 18 Effects of Insecurity Confidential Data may be stolen, e.g.: –corporate plans. –new product designs. –medical/financial records (e.g. Access bills....). Data may be altered, e.g.: –finances made to seem better than they are. –results of tests, e.g. on drugs, altered. –examination results amended (up or down). Confidential Data may be stolen, e.g.: –corporate plans. –new product designs. –medical/financial records (e.g. Access bills....). Data may be altered, e.g.: –finances made to seem better than they are. –results of tests, e.g. on drugs, altered. –examination results amended (up or down).

16. 16 CS551 - Lecture 18 Need for Security Loss of confidence: above effects may reduce confidence in systems. Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice. Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record. Loss of confidence: above effects may reduce confidence in systems. Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice. Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record.

17. 17 CS551 - Lecture 18 What’s needed for secure requests? Firewalls: Separating public and private networks Authentication: Establishing security association between client & server Access control: Deciding whether principal may perform this operation Auditing: Making the principal accountable for having requested the operation Encryption: Protecting request and response from eavesdropping in transit Non-repudiation: Proving that you have delivered a particular service Firewalls: Separating public and private networks Authentication: Establishing security association between client & server Access control: Deciding whether principal may perform this operation Auditing: Making the principal accountable for having requested the operation Encryption: Protecting request and response from eavesdropping in transit Non-repudiation: Proving that you have delivered a particular service