using Seam 2.0.2-FP with RF 3.3.0.GA and JPA 1.0 (RI) with Hibernate

I have seen the following exception in the server.log a few times for the current Seam app I'm working on:

com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 100) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Here is a helpful thread on this problem: My Link

Deadlocks are expected (though hopefully exceptional) behaviour in database applications. Rather than synchronising access to a resource that has been carefully desinged to support high levels of concurrency why not retry the thread that lost out in the deadlock? Second time round it may well work fine.

I can't repeatedly reproduce on command this exception so I'm not sure which transaction(s) are involved here and I'm not sure if it is related to processes that our DBA is running simultaneously or just isolated.  There are references to read locks in that thread and I'm wondering what default isolation level JPA and/or Hibernate is using that would force a read lock on the row(s) in question?

SQL server official documentation: My Link

READ COMMITTED

Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

What is the standard (best practice) way of handling this problem?  And is there any way to prevent it from happening?

Regarding reRun the tx, how should/can we do that using JPA/Seam/Hibernate, etc.