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

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

-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

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

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

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

Conflict Example def update1(cal, attendees): apt = Appointment(refrigerator policy, Time(2/5/ :00), Time(0:30)) cal.make_appointment(apt, attendees) def update2(cal, attendees): apt = Appointment(curly braces, Time(2/5/ :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 e55d, now c1bdd)

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

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

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

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

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

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)