hasLock(Object lock)
Most code could not use this method directly, but use InvocationContext.hasLock(Object) ()} instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

addLock

Most code could not use this method directly, but use InvocationContext.addLock(Object) instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

Note that currently (as of 3.0.0) this lock is weakly typed. This is to allow support for both MVCC (which uses Fqns as locks)
as well as legacy Optimistic and Pessimistic Locking schemes (which use NodeLock as locks). Once support for
legacy node locking schemes are dropped, this method will be more strongly typed to accept Fqn.

removeLock

Removes a lock from the currently maintained collection of locks acquired.

Most code could not use this method directly, but use InvocationContext.removeLock(Object) instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

Note that currently (as of 3.0.0) this lock is weakly typed. This is to allow support for both MVCC (which uses Fqns as locks)
as well as legacy Optimistic and Pessimistic Locking schemes (which use NodeLock as locks). Once support for
legacy node locking schemes are dropped, this method will be more strongly typed to accept Fqn.

clearLocks

Clears all locks from the currently maintained collection of locks acquired.

Most code could not use this method directly, but use InvocationContext.clearLocks() instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

Note that currently (as of 3.0.0) this lock is weakly typed. This is to allow support for both MVCC (which uses Fqns as locks)
as well as legacy Optimistic and Pessimistic Locking schemes (which use NodeLock as locks). Once support for
legacy node locking schemes are dropped, this method will be more strongly typed to accept Fqn.

hasLock

Most code could not use this method directly, but use InvocationContext.hasLock(Object) ()} instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

Note that currently (as of 3.0.0) this list is unchecked. This is to allow support for both MVCC (which uses Fqns as locks)
as well as legacy Optimistic and Pessimistic Locking schemes (which use NodeLock as locks). Once support for
legacy node locking schemes are dropped, this method will be more strongly typed to accept List.

getLocks

Returns an immutable, defensive copy of the List of locks currently maintained for the transaction.

Most code could not use this method directly, but use InvocationContext.getLocks() instead,
which would delegate to this method if a transaction is in scope or otherwise use invocation-specific locks.

Note that currently (as of 3.0.0) this list is unchecked. This is to allow support for both MVCC (which uses Fqns as locks)
as well as legacy Optimistic and Pessimistic Locking schemes (which use NodeLock as locks). Once support for
legacy node locking schemes are dropped, this method will be more strongly typed to return List.