How are the Spring @Transactional and the Hibernate @LockMode annotations related

There is no direct relationship between @Transactional and @LockMode annotations.

@Transactional is used to mark the explicit boundaries of a RESOURCE_LOCAL or JTA transaction. The reason why you need it is that every database statement executes in a transactional context, and, if you don't set the transaction boundaries, you'll get one transaction per statement or auto-commit.

On the other hand, @LockModeType is for setting explicit locking options. If you don't set it, the implicit locking mechanisms will be used:

• Implicit locks are acquired on every modified row on both 2PL and MVCC database engines. Shared locks are acquired on read records on 2PL engines if you use Repeatable Read on Serializable.
• If you defined a @Version property, the implicit optimistic locking mechanism will be used.

So, @LockModeType is for setting locking options explicitly, and you can have the following options:

• LockModeType.PESSIMISTIC_READ
• LockModeType.PESSIMISTIC_WRITE

The PESSIMISTIC lock modes will always acquire a database lock on the table row that is associated with the locked entity.

There are also explicit optimistic lock strategies:

• LockModeType.OPTIMISTIC
• LockModeType.OPTIMISTIC_FORCE_INCREMENT
• LockModeType.PESSIMISTIC_FORCE_INCREMENT

The OPTIMISTIC lock modes are meant to give you a way of bumping up an entity version even if the entity hasn't changed in the currently running Persistence Context. This is a very useful mechanism when you need to coordinate multiple child entities using their parent entity version.

There are lots of examples in the links that I provided in this answer, so take your time, read them all, and you'll understand all these concepts in greater detail.

Spring's @Transactional and Hibernate's LockMode class are different.

Spring Transaction Management

@Transactional is a Spring annotation for declarative transaction management, i.e. defining what SQL statements are executed together inside of a database transaction. Using the readOnly attribute allows Spring to throw an exception if you attempt to insert rows inside of a read-only transaction, for example.

With respect to locking, however, you'll most likely be using a read/write (readOnly = false) transaction, because you'll be attempting to modify data.

Pessimistic Locking

Hibernate's LockMode is used for pessimistic locking, e.g. LockMode.UPGRADE actually executes a SELECT...FOR UPDATE statement, and locks the row in the database corresponding to the entity.

Pessimistic locking assumes that concurrent transactions will conflict with each other, and requires resources to be locked after they are read and only unlocked after the application has finished using the data.

Optimistic Locking

Optimistic concurrency control in Hibernate typically uses a version or timestamp column in the database. The idea here is that if multiple transactions attempt to modify a row concurrently, all but the first committed transaction will detect that the version number has changed and perform a rollback.

Optimistic locking assumes that multiple transactions can complete without affecting each other, and that therefore transactions can proceed without locking the data resources that they affect. Before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rolls back.

Quotes above are from: https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html