1. Transaction Intro slide XXX New builtin get_transaction() Returns transaction for current thread ZEO manages transactions across processes, machines Transactions & Connections –Independent, consistent views of DB

2. ACID properties Atomic – All updates performed, or none Consistent –Responsibility of application –Changes should preserve object invariants Isolated –Each transaction sees consistent state –Transactions occur in serializable order Durable –After a commit, change will survive crash

3. -Concurrency control Optimistic concurrency vs. locking –ZODB assumes many more reads than writes –No locking of objects; most writes succeed so dont need to pay overhead of locking –However, conflicts can occur on writes (and in a ZEO environment, on reads too) –Conflict resolution is the applications responsibility

4. Transaction boundaries Under application control Transaction begin is implicit get_transaction().commit() get_transaction().abort()

5. Write conflicts Transactions must be serializable Two transactions change object concurrently –Only one change can succeed –Other raises ConflictError on commit() Handling ConflictError –Abort transaction, and retry –Application-level conflict resolution

6. Conflicts and Consistency New method on Calendar object def make_appointment(self, apt, attendees): self.add_appointment(apt) for person in attendees: if person.is_available(apt.date, apt.duration): person.add_appointment(apt) apt.add_person(person) –Guarantees appointments dont conflict Consider two calls at same time –Data race on is_available()? –Conflict raised when object commits

7. Conflict Example def update1(cal, attendees): apt = Appointment(refrigerator policy, Time(2/5/2002 10:00), Time(0:30)) cal.make_appointment(apt, attendees) def update2(cal, attendees): apt = Appointment(curly braces, Time(2/5/2002 10:00), Time(1:00)) cal.make_appointment(apt, attendees) Two calls at once results in one error Traceback (most recent call last): File, line 1, in ? File ZODB/Transaction.py, line 233, in commit File ZODB/Connection.py, line 347, in commit File ZODB/FileStorage.py, line 634, in store ConflictError: database conflict error (serial was 034144749675e55d, now 03414442940c1bdd)

8. Object serial numbers Every object has a serial number –monotonically increasing –might be a timestamp –a.k.a. revision number, transaction id Upon commit, current serial number is compared to stored serial number. If they differ, object has been modified externally in the interim: ConflictError is raised Upon successful write, object gets a new serial number

9. Dealing w/write conflicts Depends on the application! from ZODB.POSException import ConfictError while 1: try: obj.counter += 1 get_transaction().commit() except ConflictError: pass else: break

10. Dealing w/write conflicts cont Whats (possibly) wrong with this picture? obj.counter += 1 while 1: try: get_transaction().commit() except ConflictError: pass else: break

11. Read conflicts with ZEO When using ZEO, it is possible to get ConflictErrors on reading an object –Storage servers send invalidation messages to clients when an object changes –Invalidation messages are only visible at transaction boundaries –Clients read only most current object revision Future: Multi-version concurrency control Now: get_transaction().abort() and try again

12. Application level conflict resolution Objects can implement their own (write) conflict resolution logic Implement _p_resolveConflict() method –args: oid, old serial #, new serial #, current pickle data –returns: new pickle data or None –None signals a ConflictError

13. Subtransactions You can create subtransactions within a main transaction –individually commit and abort subtransactions –not truly committed until containing transaction is committed Primarily for reducing in-memory footprint >>> get_transaction().commit(1)