I'll get there eventually. . . .
Am I correct in stating that for MDBs they will not use a pooled
connection to the JMS resource then? (Only the pool of MDBs) Back in
the days of AS7 we had found that there were issues in connecting an MDB
to a Sun MQ cluster of brokers when performing XA transactions with the
database. If my memory serves me correctly this was due to the fact
that the external JMS resource was not pooled and hence the final commit
could occur on a different connection. Could this be an issue that we
may come across again?
What is your reasoning behind stating that the inbound connection is not
"critical" With a JMS queue I see getting a message produced to be of
equal importance with consuming that message.
A bit of stuff that I still do not fully understand round how the
deployment descriptors and the AS container interact. Time I read the
specifications/tutorials again carefully!
Many thanks
Donald
Binod wrote:
> Donald Forbes wrote:
>
>> Not sure if I fully understand your answer. Does that mean that an
>> MDB does not make use of the Connector resources (pools & admin
>> objects). In which case does it need the jndi names for the
>> connection factory and destination? Or do you mean that all the
>> activation config is optional for MDBs connecting to a queue via the
>> genericra?
>
>
> Yes. InboundCommunication dont (and should not) use connector
> resources and pools, as ActivationSpec and ManagedConnectionFactory
> are two different javabeans specified by connector spec.
>
> And, yes, all the activation config properties are optional. If you
> need to specify some thing, that can be
> put in the ejb-jar.xml itself. sun-ejb-jar.xml is just a mechanism to
> override, what you can specify
> in the ejb-jar.xml.
>
> The issue will be further complicated as there is not much use case for
> dynamic reconfiguration of activation spec. There is no recommendation
> for RAs from connector spec on how to handle the dynamic reconfiguration
> of javabeans.
>
> For outbound connections, atleast the pool configuration is managed by
> application
> server and can be dynamically reconfigured. That is one of the
> motivation for
> moving a configuration to domain.xml from deployment descriptor.
>
>>
>> I can understand why the outbound connection is very important for
>> other resouces but for queues I would think that the inbound is just
>> as important as the outbound.
>
>
> I agree that it is important. At the same time, it is not very critical.
> So, we should file an RFE against SJSAS.
>
> - Binod.
>
>>
>> Kind regards
>>
>>
>>
>> Donald
>>
>> Binod wrote:
>>
>>> Hi Donald,
>>>
>>> Good question.
>>>
>>>>
>>>> When configuring the genericra you deploy the generic RA itself and
>>>> give it details on where the LDAP store is, the base org unit to
>>>> work from, username, password etc. Then you configure the
>>>> connection factory pool and destination objects that result in
>>>> entries in the app server JNDI space. These entries refer to an
>>>> actual entry in the directory server. (eg.
>>>> cn=QueueConnectionFactory & cn=QueueDestination) When using an
>>>> MDB it seems that the activation spec must contain the LDAP lookup
>>>> values as well. Should it not be possible for the directory
>>>> entries to be specifed in the domain.xml rather than in the
>>>> deployment descriptors for the actual application?
>>>
>>>
>>>
>>>
>>> For MDBs, the activation-config-properties are not directly
>>> configured the descriptor. Sun application server do not have a
>>> way to create an inbound-activation-resource. Quite honestly,
>>> there wasnt much demand for such a featire in application server.
>>>
>>> Infact, the resource-ref, that facilitates the indirection in case
>>> of outbound connections is used for all kind of resources [eg: jdbc]
>>> and not only resource adapters. That is one reason, why
>>> inbound-activation-resource did not become a priority.
>>>
>>> thanks,
>>> Binod.
>>>
>>>>
>>>> Many thanks for any thoughts round this area.
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> Donald
>>>
>>>
>>>
>>>
>>>
>>>
>
>