Good morning,
Agree with that.
Singleton is a component not kinda qualifier.
There is actually a "similar" question regarding Stateless (EJB_SPEC-79)
and the way to only use one single instance for all threads.
So once again, using Singleton on stateless seems not better ...
So we still have the attribute solution (as you proposed IIR) or creating
yet another annotation to use as a qualifier.
Would like to get thoughts (for more experienced guys) ;-)
Jean-Louis
2013/1/3 Marina Vatkina <marina.vatkina_at_oracle.com>
> Jean-Louis,
>
> I'm all for it, but if we add it, we need to do so very quickly.
>
> The problem with @Singleton reuse (even though it maps very nicely in
> general and into the rules and rules of concurrency in particular), is that
> @Singleton is a component-defining annotation for the "singleton session
> beans". If we are to reuse it, the rule will become "unless it is an MDB",
> which is a bit odd...
>
> Carlo, Antonio, others, WDYT?
>
> thanks,
> -marina
>
>
> On 1/2/13 2:39 AM, Jean-Louis MONTEIRO wrote:
>
> Marina,
>
> time to reactivate the discussion on Single MessageDrivenBean instance.
> FYI, a similar issue has been created.
>
> http://java.net/jira/browse/EJB_SPEC-80
>
> As for Stateless versus Singleton, I think it could be fine to be able
> to only have one instance.
>
> Jean-Louis
>
>
>
>
> 2012/9/20 Marina Vatkina <marina.vatkina_at_oracle.com>
>
>> I understand your concern, though it is a question of what is more
>> confusing...
>>
>> Experts,
>>
>> Before we decide on *how* to specify a single MDB instance, do you think
>> it *is* useful to be able to have one?
>>
>> thanks,
>> -marina
>>
>> Antonio Goncalves wrote:
>>
>>> Like Carlo I was thinking of reusing @Singleton. The EE platform
>>> already has 3 (javax.ejb.Singleton & javax.inject.Singleton &
>>> @ApplicationScoped) which already confuses people. I understand the
>>> technical issues that you express Marina, I'm just a bit disapointed to
>>> think that we have another way to have singletons.
>>>
>>> Antonio
>>>
>>> On Wed, Sep 19, 2012 at 1:05 AM, Marina Vatkina <
>>> marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>>>
>>>
>>> Carlo de Wolf wrote:
>>>
>>> Thinking out loud I would find it counter-intuitive, rather I
>>> would think @Singleton @MessageDriven. Taking it a bit farther
>>> @MessageDriven can actually be construed to be a view instead
>>> of a component type. The component type would, by default, be
>>> like a stateless session bean.
>>>
>>>
>>> Let's not go too far from the current MDB setup ;) As we discussed
>>> it before, any major changes to MDBs would require substantial
>>> changes in the JCA spec, which is not possible in the MR release
>>> (i.e. without a JCA EG).
>>>
>>>
>>> Even without going over that hurdle, the question also raises
>>> thinking about locking. Sooner or later somebody is going to
>>> make that leap.
>>>
>>>
>>> Right. This is why I was suggesting an attribute on a
>>> @MessageDriven. It can have a simpler requirements and no
>>> confusion with a singleton *session* bean (that a @Singleton
>>> defines).
>>>
>>> Theoretically speaking, even now (see the example in David's
>>> proposal), a connector impl gets a hold of the proxy and use it
>>> however it sees it fit (in David's example it uses it as a
>>> singleton), and cause a deadlock or any non-thread-safe behavior.
>>> So if the single-instance MDB is defined as only a responsibility
>>> of the MDB container not to create a new instance and serialize
>>> access to it, it will solve the ordering problem without bringing
>>> in additional features.
>>>
>>> Does it make sense?
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>> Carlo
>>>
>>> On 09/15/2012 02:18 AM, Marina Vatkina wrote:
>>>
>>> Experts,
>>>
>>> While you are thinking about David's proposal (as I hope
>>> you all do ;) ), here is another question: do we need to
>>> provide a standard way to guarantee a single MDB instance
>>> running in a server instance? I do not propose support for
>>> all other features available to the singleton session
>>> beans, just a guarantee of a single MDB instance.
>>>
>>> In GlassFish (RI) we had this request to support message
>>> ordering processed by the MDB.
>>>
>>> If you think that it is useful, we can add an attribute
>>> (e.g. 'isSingleton') to the @MessageDriven annotation that
>>> would default to false for backward compatibility.
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect and Java Champion
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter <
>>> http://twitter.com/agoncal> | LinkedIn <
>>> http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>
>>> | Devoxx France <http://www.devoxx.fr>
>>>
>>
>
>
> --
> Jean-Louis
>
>
>
--
Jean-Louis