Chiming in. As it's really the Resource Adapter that controls the
lifecycle of the MDB this might not be the most natural.
Specifically, the contract is:
- MessageEndpoint messageEndpoint =
MessageEndpointFactory.createEndpoint() -- creates an MDB instance,
causes @Inject'ion, then @PostConstruct
- messageEndpoint.release() -- destroys the MDB instance, causes
@PreDestroy to be called.
So currently it's actually the Resource Adapter that pools the MDB
instance. The Resource Adapter already has the ability to create just
one instance if it chooses. What the RA doesn't have the ability to
do -- or at least it is not explicitly stated it can -- is
concurrently invoke the MDB instance.
One possible solution is to simply allow @Lock to be used on the MDB
class? The MDB container would enforce the locking mechanism in the
endpoint.beforeDelivery call and release said lock in
endpoint.afterDelivery, which is where transaction and security work
are currently done.
-David
On Mon, Jan 14, 2013 at 12:20 PM, Marina Vatkina
<marina.vatkina_at_oracle.com> wrote:
>
> On 1/12/13 7:03 AM, Philippe Marschall wrote:
>>
>>
>>
>> On 03.01.2013 17:27, 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.
>>
>>
>> What adding singleton=true to Stateless and turning Singleton into a
>> stereotype?
>
>
> This is not supported in Java EE 7 - standard annotations cannot be turned
> into stereotypes.
>
> -marina
>
>>
>> @Stereotype
>> @Stateless(singleton=true)
>> public @interface Singleton {
>> }
>>
>> Cheers
>> Philippe
>>
>