Hi Martin,
On Aug 25, 2008, at 4:33 AM, Martin Vysny wrote:
Hi David,
impressive work indeed, thank you very much! I am especially grateful
for the Singleton and Startup functionality which I missed.
Thanks! It's definitely great to have a standard way to do this in
the EJB world.
I have one
question: in your example (the ComponentRegistryBean example) a simple
HashMap is used which is thread unsafe. Does that mean that only a
single thread (the one which created the bean) will access the bean?
Nope, that's not it - multiple threads can access methods with
Lock.READ. What does the specification say about the thread
safety/multithreading issues? Must the bean be thread-safe or
container
will mark all methods as synchronized? Can the user code rely on some
locking mechanisms (or invariants) performed by the container (for
example, will Lock.WRITE always perform lock on the bean class?)
Sorry if it is a dumb question and I'm missing something obvious :)
Good feedback. Thank you for sending it!
Clearly my explanation is not doing what it should :) I do see a bug
too now that I look closer, too. The getComponents() method should
return a copy of components.values() or someone could get a
ConcurrentModificationException.
I've changed/expanded on the text in the example. Pasted it here
below as well. Let me know if it's any better. We'll keep trying
till we get something that's easy to understand and doesn't leave the
reader with a bunch of questions.
Unless specified explicitly on the bean class or a method, the
default @Lock value 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.
Essentially @Lock(READ) allows multithreaded access to the
Singleton bean instance unless someone is invoking an
@Lock(WRITE) method. 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.
The end result is that the threading model for this bean will
switch from multi-threaded access to single-threaded access
dynamically as needed depending on the which methods are being
invoked. This gives Singletons a bit of an advantage over
Servlets for processing multi-threaded requests.
http://cwiki.apache.org/OPENEJBx30/singleton-example.html
Feel free to kick it back with changes/tweaks or other questions.
Sometimes a word added here or there can make things more clear.
These docs are likely going to be a primary source of singleton
information for a while so we definitely want them to be as
informative as possible.
-David
