To understand phantom deadlock, you need an understanding of deadlock in general, distributed deadlock and mechanisms used to detect and resolve deadlock, so I'll introduce these concepts one by one.
Deadlock can occur in systems that implement locking for concurrency control during transactions, so these systems need some kind of mechanism to detect this and resolve the problem when it occurs.
One way to detect deadlock within a single system is to use what's known as a Wait-for graph, deadlock has occurred when there is a cycle within the graph and can be resolved by aborting one of the transactions/processes.
Deadlock can also occur in distributed systems where transaction locks are held in different servers, this means that the loop in the entire wait-for graph will not be apparent to any one server. A solution to this problem is to introduce a coordinator to which each server forwards it's wait-for graph, the idea here is that the coordinator will be able to produce a wait-for graph for the entire system and can therefore make a decision about which process/transaction should be aborted to resolve the deadlock.
The above introduces another potential problem known as Phantom Deadlock. This is when the information gathered at the coordinator regarding each servers wait-for graph is out of date, so a transaction may have released a lock, but the global wait-for graph shows it as still holding. Thus a deadlock might be detected that never existed!
