Glassfish requests had the same reasons.
-marina
On 1/7/13 1:50 AM, Jean-Louis MONTEIRO wrote:
> 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
> <mailto: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
>
> 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>
> <mailto: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>>
> <mailto: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