Donald Forbes wrote:
> 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
The pooling (if there is any) in case of MDB's internal resources is
done by RA and not by application server.
Generic RA contains a pool of server sessions (not connections) for
facilitating concurrent delivery.
This can be tuned in the deployment descriptor.
MDB instances can be pooled by an application server. These days, JVM
has matured enough
to tune itself to handle object creation so much that MDB instance
pooling does not make much sense.
Sun application server doesnt *really* pool the instances. It allows
user to specify a threshold to limit
the maximum number of MDB instances that get created. That is to safe
guard against
memory starvation and not for object caching.
> 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?
I am not aware of such an issue in AS7. However, so far in our testing,
we did not face any such
issue with generic RA.
>
>
> 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.
Inbound communication is not critical to be configured outside the
deployment descriptor,
especially since the inbound dynamic reconfiguration is not covered by
connector spec. Very
few resource adapters are going to support it. So, it is probably just
adding one more level
of indirection without much benefit.
I wasnt saying that inbound messaging itself is not critical at all.
It definitely is critical :-)
thanks,
Binod.
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>