If I am reading the deadlock graph correctly, these are the processes involved.
PAGE LOCKS
PageID Owner Waiter
288119 process195156188 process1dff40188
288279 process195156188 process251742928
288279 process251742928 process226ae0188
288119 process1dff40188 process226ab1868
EXCHANGEEVENT
Id Owner Waiter
Pipe1b9b02a80 process226ab1868 process195156188
Pipe1b9b02a80 process226ae0188 process195156188
So it is not just two guys fighting it out with each other, it is a multi-participant deadloc. The presence of EXCHANGEEVENT is an indication of locks due to parallelism. But if the only activity involves updating a single row based on a clustered key, this shouldn't be an issue, except, as you suggested, it might be related to the presence of the text column (which, unlike varchar(max) is always stored off-row)
Anyway, I am not offering any solutions; if you are able to reproduce the issue in a dev environment, two things might be worth experimenting with:
- Setting MAXDOP=1 and testing to see if the problem goes away.
- Changing the text column to VARCHAR(MAX) to see if that has any impact.
In any case, I would be very interested in learning how you resolved the issue when you eventually do.