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