I am still troubleshooting deadlock mentioned in this questions. In that I got help in understanding why a select would hold on to a shared lock and I was able to test and confirm that also.
Now I am looking at second spid involved in the deadlock. That session does an update using a primary key(WHERE BatchId = @BatchI , BatchId is the PK) and it needs IX on two pages. Initially I couldn't figure out why it needed locks on two pages of a non clustered index when it was just updating one row. Then I realized that the update to that row would change the location of the row in the non clustered index and that could be reason why it needs locks on two pages.
Is that correct?
Secondly, please help confirm my understanding of this deadlock is correct. For simplicity sake lets assume that here are only two pages in that non clustered index. Page1 and Page2. So is this what is roughly happening