How it works...

The first thing to have a look at is the following:

@ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)

This is completely redundant! Singleton beans are container-managed by default, so you don't need to specify them.

Singletons are designed for concurrent access, so they are the perfect use case for this recipe.

Now, let's check the LockType defined at the class level:

@Lock(LockType.READ)
@AccessTimeout(value = 10000)
public class UserClassLevelBean {
    ...
}

When we use the @Lock annotation at the class level, the informed LockType will be used for all class methods.

In this case, LockType.READ means that many clients can access a resource at the same time. This is usually used for reading data.

In the case of some kind of locking, LockType will use the @AccessTimeout annotation time defined to run into a timeout or not.

Now, let's check the LockType defined at the method level:

@Lock(LockType.READ)
public int getUserCount(){
      return userCount;
}
    
@Lock(LockType.WRITE)
public void addUser(){
      userCount++;
}

Here, we are basically saying that getUserCount() can be accessed by many users at once (LockType.READ), but addUser() will be accessed just by one user at a time (LockType.WRITE).

The last case is the self-managed bean:

@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class UserSelfManagedBean{

    ...

    public synchronized void addUser(){
        userCount++;
    }
 
    ...
}

In this case, you have to manage all the concurrency issues for your bean in your code. We used the synchronized qualifier as an example.