Good question (though it doesn't seem that David's proposal can make it
into EE 7). I think it's somewhat orthogonal - the RA can request
instances as it needs, but the MDB can be setup to handle all requests
via a single instance.
Experts?
thanks,
-marina
On 1/4/13 5:07 AM, Jean-Louis MONTEIRO wrote:
> Marina and all,
>
>
> Just another thought.
> Regarding David's proposal (modernize connector), does singleton still
> make sense?
> I mean, do we have a JMS only use case in mind or does it really fit
> all connector potential usages as per David's proposal for example?
>
> Jean-Louis
>
>
>
>
> 2013/1/3 Marina Vatkina <marina.vatkina_at_oracle.com
> <mailto: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
>> <mailto: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>
>> <mailto: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