Question

There’s lots that can be taught about transactions in databases (and I’m really talking about relational databases here, since that’s what I’m currently teaching), but I believe it’s easy to teach the wrong things. Given that students are very likely going to forget most of what you say before they leave the lecture room, where should the focus go?

Some key topics that often feature in textbooks and lecture slides are (going by Ramakrishnan and Gehrke as a main guide) – but don’t feel restricted by them:

• ACID properties
• schedules and their serializability
• conflict serializability and precedence graphs
• SQL transaction statements (COMMIT, ROLLBACK, SAVEPOINT)
• locking protocols (Strict 2PL and such)
• isolation levels (READ COMMITTED, REPEATABLE READ, etc.)
• logging and recovery (WAL, ARIES)
• transaction support in APIs (JDBC, PHP)

I’m after an informed view of what topics are most worthwhile, and what’s not. I’m also interested in where you’re coming in from in answering. Have you found some nugget of insight invaluable in a job, or are you frustrated that newly graduated employees don’t know some basic detail?

Background: I’m teaching the topic in an introductory DBMS course to students of a 1-year IT Masters course. The students are computer-literate (mostly CS) graduates.

Answer 1

First of all: is your focus using transactions or implementing them? What is the background of the students – particularly, do they understand concurrency?

My opinion as a non-DB expert who nevertheless needs to use them all the time:

• I think the actual SQL statements are just a detail; they are worth including to make them less menacing in practice, but let em look up the syntax themselves. You could intentionally use a variety of syntaxes (eg. using APIs) simply to get across the point that it’s not the name that matters, but the idea and API contract a transaction represents.
• Understanding isolation levels is required – at least up to a point; they should understand that life isn’t always SERIALIZABLE, why one would (almost always) chose that handicap, and what kind of problems to watch out for. Oh, and various SNAPSHOT varieties should be included (I’m mentioning this explicitly since these in particular don’t always show up in lectures yet are very widely used.)
• Locking (or the lack thereof) is obviously related to the isolation levels and their advantages and disadvantages. In particular, minor seemingly irrelevant changes to a transaction can affect the order in which locks are acquired and thus the presence and absence of deadlocks. In that respect it may be important; but otherwise it’s an implementation detail (from my perspective) preferably ignored.
• In terms of ACID, an understanding that it’s not an all or nothing affair and that it can be quite useful to give up parts in return for other (particularly performance) benefits.
• Perhaps it’s neat to point out that lots of apps use databases, even desktop apps, partially because the simple, robust guarantees of a DB make it easier to do persistence (e.g. sqlite in firefox or adobe reader) with than raw I/O. Anybody doing programming is likely to occasially touch a DB; there’s almost no avoiding it: and you wouldn’t want to since the atomicity and consistency guarrantees are valuable even in a non-concurrent context (if your PC crashes, your lightroom DB isn’t corrupted).
• Also, it should be clear that in a DB (in general) all statements are executed in an implicit transaction; you’re not avoiding transactions by avoiding the explicit transaction statements, merely using more, smaller transactions which can still deadlock and cause locking or fsync overhead. In otherwords: if the students want to work with a DB (which they almost inevitable will have to and will want to) they simply cannot avoid transactions.

Background: I write webapps at work and other stuff for fun.