Phantom

When a write operation in one transaction changes the result of a search query (already executed) in another transaction, the effect is called a Phantom.

Phantoms happen when the decision taken by a transaction based on the application state turns out to be inaccurate by the time it commits. In that sense, phantoms are not Dirty Reads because the data is already committed.

Take a Meeting Room Booking application as an example. A room booking operation runs a Read-Modify-Write cycle to add bookings - it checks for existing bookings for a specific timeslot and adds a reservation if it finds none. Suppose two room-reservation transactions were to execute simultaneously. In that case, their initial data fetch may return no booking records, causing the transaction that runs second to take an incorrect decision to insert a conflicting reservation.

Phantoms can be prevented entirely with Serializable Isolation - they wouldn't occur if the transactions were run serially.

Phantoms will not happen if there objects in the database that we can attach locks to, forcing subsequent transactions to wait to fetch data. In some cases, it is possible to prevent phantoms by materializing them into lock conflicts on concrete rows. But this approach should be the last resort for an application because implementing it means that concurrency-control concerns have leaked into the application data model.