The power of locking as a primitive for controlling concurrency in database systems is examined. It is accepted that the concurrent execution (or schedule) of different transactions must be serializable; that is, it must behave like a serial schedule, one in which the transactions run one at a time. It is shown that locking cannot achieve the full power of serializability. An exact characterization of the schedules that can be produced if locking is used to control concurrency is given for two versions of serializability. In the first one, state serializability, only the effect of the schedule on the database is taken into account. In the second one, view serializability, the view of the data received by the transactions is also taken into account. The author shows that it is possible to determine efficiently whether the transactions in a given set can be permitted to run safely by themselves without the need of any control while ensuring view serializability, although the problem is np-complete in the case of state serializability. 20 references.