Well I don't know about URLyBird, but looking at the instructions for Contractors (Bodgitt & Scarper) although the DB interface does have a number of specific requirements for its functionality, and there's a requirement that the whole program be thread-safe, it's not actually required that the
thread safety be implemented
inside the DB interface. It is, indeed, possible to put this in a separate class if you like. You could even make a second class which implements the same interface and is a synchronized wrapper for the main implementation - much like Collections.synchronizedMap() creates a synchronized wrapper object containing a normal Map inside. You could also put more elaborate sync logic in this wrapper class - e.g. it could contain read and write locking logic, or even a bunch of RecordLock objects for record-level locking. This is similar to my record-level locking on the cached Record object, except that a RecordLock object does not contain any data about the record other than whether it's locked or not, and what the cookie is (if your assignment uses cookies). And if you do use full caching, the Record objects are used only for record data, not for locking. Thus record locking can be completely independent of record caching.
Now, I don't know offhand if there's a compelling argument either way about whether this level of separation is
desireable. I haven't implemented this sort of separation myself, and doubt I will; I don't see a need to refactor my classes again.
But I'll certainly agree it's possible at least.