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>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>