You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by howard goldberg <go...@gmail.com> on 2009/03/21 23:00:01 UTC
singleton instantiation vunerability
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
Re: singleton instantiation vunerability
Posted by howard goldberg <go...@gmail.com>.
David,
Thanks for the fix. Keep up the good work!
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
>
>
Re: singleton instantiation vunerability
Posted by David Blevins <da...@visi.com>.
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
Re: singleton instantiation vunerability
Posted by David Blevins <da...@visi.com>.
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.
-David