On Mar 24, 2009, at 7:33 PM, David Blevins wrote:
On Mar 21, 2009, at 3:00 PM, howard goldberg wrote:
I started testing my ejb services with a multi-threaded client, and
noted
that my singleton ejb was being instantiated multiple times.
When I annotated the singleton with @startup, the singleton was
appropriately only instantiated once. I subsequently increased the
interval
between client thread instantiations, (after removing @startup) and
the
number of singleton instantiations diminished. When using lazy
instantiation, the singleton appears vulnerable to multiple
instantiations
if called concurrently.
Howard, thank you very much for reporting this.
I've been hacking on this and should hopefully have something for
you tomorrow or the next day. Taking the opportunity to also add
transactional PostConstruct methods, @AccessTimeout support and a
couple other Singleton items that were added to the EJB 3.1 spec
recently.
This issue has been filed and fixed:
https://issues.apache.org/jira/browse/OPENEJB-1012
The new code uses an AtomicReference to hold a FutureTask object. The
thread to win the Atomic compare and swap operation is the thread that
will construct the singleton via futureTask.run().
I also added a test case that uses a CyclicBarrier to queue up a few
hundred threads to reproduce the race condition as optimally as
possible. All looks good.
Howard, thank you again for reporting the issue.
-David
