Facing Deadlock during Parallel Updates even when "with(rowlock)" is specified

Hi,

Brief Description about the process

1.  We have some update statements running in parallel on a log table.
2.  Structure of the Log Table is as below

      CREATE TABLE [dbo].[PackageTaskLog](

            [PackageTaskLogID] [int] IDENTITY(1,1) NOT NULL,

            [PackageLogID] [int] NOT NULL,

            [SourceName] [varchar](255) NOT NULL,

            [SourceID] [uniqueidentifier] NOT NULL,

            [StartDateTime] [datetime] NOT NULL,

            [EndDateTime] [datetime] NULL,

      CONSTRAINT [PK_PackageTaskLog] PRIMARY KEY CLUSTERED

       (

               [PackageTaskLogID] ASC

         )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY =        OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON          [PRIMARY]

        ) ON [PRIMARY]

 3.      The Update statement is as below

             UPDATE dbo.PackageTaskLog with (RowLock)

             SET EndDateTime = getdate()

             WHERE PackageLogID = @PackageLogID AND SourceID = @SourceID

              AND EndDateTime is null

4.  At any point of time, combination of PackageLogID and SourceID will be distinct.

Currently we are facing some deadlock errors.

Information about the DeadLock

1.  We had this deadlock issue around 4 months back. At that point of time, the update statement did not have with (RowLock). After adding this option, we thought deadlock issue was resolved.

2.  But again, we faced this deadlock issue last week. Below image provides the deadlock graph

3. According to the below link, they suggest to make the query as index seek.

http://social.msdn.microsoft.com/forums/sqlserver/en-US/dba45618-1d64-4661-891d-74cab09dddf1/deadlock-while-running-multiple-update-statements

      (Currently in my query Clustered Index Scan is happening)

But my doubt is, if we make index seek, suppose if it locks a particular page, again we may end up having deadlock.

4. Also, one more point is that, since it was log table, we took data back up and truncated the table. And now since 4 days deadlock is not occurring.
5. Also, one more point is that, since it was log table, we took data back up and truncated the table. And now since 4 days deadlock is not occurring.

Clarifications Needed

Because of above points, I have some clarifications which are listed below

1. If we create non-clustered index and force the update statement to use that index, will it resolve the issue. Will it lock the page or will it pin-point exact row and lock it.

2.  Also, in below link they mentioned that Update locks will prevent deadlock. They mentioned that if an Update lock is issued, then other process has to wait until this Update lock is released.

http://technet.microsoft.com/en-us/library/aa213039(v=sql.80).aspx

But, in the above deadlock graph, we see that Update lock and exclusive locks were involved.

I did not understand how Update lock was involved in my Update statement, even though I did not mention it in my update statement.

Whether the update lock in the deadlock graph and the Update lock mentioned in the above link are different?

3. Can I embed this Update statement in a transaction and set transaction isolation level as “serializable”. Will it resolve my issue?

4. Also, I want to know why deadlock did not recur after truncating the table. Original log table had around 944,771 records.

This is actually a data warehouse. In transactional database they have so many DML operations running in parallel. How do they handle it in transactional database?

Basically, how can we permanently eliminate this deadlock issue?