What does this deadlock report from MySQL mean?
You didn't specify what language your code was in, but it appears that the PESSIMISTIC_WRITE is causing a FOR UPDATE type of select.

As such, the following is happening:

Transaction A

SELECT * FROM pings where id = '52c7e28eebb26a86fb1505b5' FOR UPDATE;


Transaction B

SELECT * FROM pings where id = '52c7e28eebb26a86fb1505b5' FOR UPDATE;


At this point, both transactions are holding a lock on the space you want to insert into.

Transaction A (continuing)

insert into pings (lastProcessTime, id, type) values (1450845, '52c7e28eebb26a86fb1505b5', 'INCIDENT')


Transaction A at this point will wait, as it wants B to release its lock before it continues.

Transaction B (continuing)

insert into pings (lastProcessTime, id, type) values (1450848, '52c7e28eebb26a86fb1505b5', 'INCIDENT')


However, B not only didn't release its lock, but it wants to insert the same record. The database says no way, and forces one (B, in this case) to deadlock and be undone.

This is actually extremely easy to replicate yourself. Just start 2 transactions (I used two Terminal windows to connect to my MySQL instance), one for each transaction, A and B. Start each with START TRANSACTION, and then just enter the commands in the same order as above, in each respective window. Any table with any primary key will work, just adjust the statements to each try to insert the same row.

Once you submit the second insert, you'll see the deadlock (generally applied to the transaction that tried to insert second.)

So, your issue is fully expected, as the FOR UPDATE on the SELECT statement is doing exactly what it is intended to do (which is to keep other transactions from changing the result of the SELECT until the transaction ends.) 

Edit: Well, fully expected except for the fact that one would expect the SELECT ... FOR UPDATE to wait, regardless of whether there are any rows returned for the SELECT. However, if there are no rows, the behavior is as described above, but if there are rows returned, Transaction B will wait before returning any results from its SELECT. See this the bug report on this issue.

I would suggest changing your code to check for a duplicate key after inserting (either catching the exception or using ON DUPLICATE KEY ...), rather than trying to do a SELECT ... FOR UPDATE and then an insert.