EJB_SPEC-79 is a separate discussion...
Let's say we do use the attribute. What would be the concurrency
support? CMC *and* BMC ? Or only one (which)?
I don't see a problem with supporting both concurrency types (as it will
be very similar to the @Singleton).
WDYT?
thanks,
-marina
On 1/3/13 8:27 AM, Jeremy Bauer wrote:
> I also do not like the idea of re-using @Singleton because it is a
> component defining annotation. If we are just talking about a single
> switch, adding an attribute to the annotation ex.
> @MessageDriven(singleton=true) is my preference.
>
> -Jeremy
>
>
>
> From: Jean-Louis MONTEIRO <jeanouii_at_gmail.com>
> To: jsr345-experts <jsr345-experts_at_ejb-spec.java.net>,
> Date: 01/03/2013 02:06 AM
> Subject: [ejb-spec users] [jsr345-experts] Re: Singleton MDB?
> ------------------------------------------------------------------------
>
>
>
> 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_
> <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_
> <http://www.antoniogoncalves.org/>> | Twitter
> <_http://twitter.com/agoncal_> | LinkedIn
> <_http://www.linkedin.com/in/agoncal_> | Paris JUG
> <_http://www.parisjug.org_ <http://www.parisjug.org/>> | Devoxx France
> <_http://www.devoxx.fr_ <http://www.devoxx.fr/>>
>
>
>
> --
> Jean-Louis
>
>
>
>
> --
> Jean-Louis