row-level locks are better for maximum concurrency than table-level locks.
the side effect of lock escalation from row level lock to table level lock is its impact on other applications running concurrently. It may block other applications from accessing the table.
For example, if application A holds a shared table lock on a table, it blocks other applications from updating any rows in the table, because they would need to acquire an exclusive lock on a row in that table.
Further, it has to be ensured that lock escalation ( Converting row level locks to table level locks by database manager) does not occur for the reasons mentioned above. Inorder to avoid lock escalation it is recommented to practice the foll...
. commit your transactions often
. If possible, reschedule the applications that compete for access to the same table. Also, use Uncommitted Read [meaning dirty read] transactions where read consistency is not an issue.
when we changing the lock size row to table
if multiple users are using the same table then it is not possible to them to use the table so that they have to wait for releasing of lock
in some situations like if u want to just read a row from the table it is not necessary to issue a table lock it makes other users users to kept into the waiting state so that degrades the system performance