Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Here we see a bean that uses the Container-Managed Concurrency option, the default. With @ConcurrencyManagement(CONTAINER) the container controls whether multi-threaded access should be allowed to the bean (@Lock(READ)) or if single-threaded access should be enforced (@Lock(WRITE)).

Wiki Markup
{snippet:url=openejb3/examples/simple-singleton/src/main/java/org/superbiz/registry/ComponentRegistryBean.java|lang=java|id=code}

The default @Lock value for a method is @Lock(WRITE). The code above uses the @Lock(READ) annotation on bean class to change the default so that multi-threaded access is granted by default. We then only need to apply the @Lock(WRITE) annotation to the methods that modify the state of the bean. The important thing to keep in mind is that when

Essentially @Lock(READ) allows multithreaded access to the Singleton bean instance unless someone is invoking an @Lock(WRITE) method is invoked the container will block all access to the bean, even to @Lock(READ) methods, until the method completes. This is very good and is an advanced form of synchronization that allows for safe multi-threaded reading and single-threaded writing. With @Lock(WRITE), the thread invoking the bean will be guaranteed to have exclusive access to the Singleton bean instance for the duration of its invocation. This combination allows the bean instance to use data types that are not normally thread safe. Great care must still be used, though.

In the example we see ComponentRegistryBean using a java.util.HashMap which is not synchronized. To make this ok we do three things:

  1. Encapsulation. We don't expose the HashMap instance directly; including its iterators, key set, value set or entry set.
  2. We use @Lock(WRITE) on the methods that mutate the map such as the put() and remove() methods.
  3. We use @Lock(READ) on the get() and values() methods as they do not change the map state and are guaranteed not to be called at the same as any of the @Lock(WRITE) methods, so we know the state of the HashMap is no being mutated and therefore safe for reading.

Test Case

Wiki Markup
{snippet:url=openejb3/examples/simple-singleton/src/test/java/org/superbiz/registry/ComponentRegistryBeanTest.java|lang=java|id=code}

...