Hi Linda,
the 2 main reasons I already saw in my company were:
- guarantee messages ordering
- and avoid pool overhead when not necessary
Jean-Louis
2013/1/5 Linda DeMichiel <linda.demichiel_at_oracle.com>
> I would really like to understand the target use cases here better before
> deciding how or whether to proceed with this.
>
> Is the goal:
> - guaranteed ordering of message receipts ?
> - ability to maintain state in the singleton instance ?
> - avoid bean pool exhaustion ?
> - other ??
>
> Other than the recent JIRA issue posted, what user requests have we
> gotten in this area?
>
> thanks,
>
> -Linda
>
>
>
>
> On 1/2/2013 3:01 PM, Marina Vatkina wrote:
>
>> 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<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 <mailto:
>>> marina.vatkina_at_oracle.**com <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>
>>> >
>>> <mailto:marina.vatkina_at_oracle.**com <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
>>>
>>
>>
--
Jean-Louis