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<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<http://www.antoniogoncalves.org>>
>> | Twitter <http://twitter.com/agoncal> | LinkedIn <
>> http://www.linkedin.com/in/**agoncal <http://www.linkedin.com/in/agoncal>>
>> | Paris JUG <http://www.parisjug.org> | Devoxx France <
>> http://www.devoxx.fr>
>>
>
--
Jean-Louis