Donald Forbes wrote:
> Hi Binod,
>
> I have been doing some more reading about the connector architecture
> 1.5 and J2EE 1.4 in general and I am gradually coming up to speed.
> Technically I should have been diving into the documentation before
> trying things out but . . . .
>
> Anyway, I recently read on the server side
> (http://www.theserverside.com/articles/article.tss?l=MonsonHaefel-Column6)
> the following statement:-
>
>
> "There is a significant difference in how EJB 2.0 and EJB 2.1 define
> message-processing properties of a MDB in the deployment descriptor.
> EJB 2.0 defined a couple of JMS-specific elements, <message-selector>
> and <acknowledge-mode>, which have been replaced in EJB 2.1 so that
> the MDB deployment descriptor can represent both JMS-based MDBs and
> connector-based MDBs. Because connector-based MDBs may not use JMS as
> the message service, a message-agnostic element, <activation-config>,
> was introduced to describe the messaging properties of the MDB. The
> /Activation Configuration/ properties are passed to the Connector when
> the MDB is deployed. The Connector will use these properties to
> configure the way it delivers messages to the MDB."
>
> My reading of this is that because using a connector architecture can
> be used for delivering messages to a J2EE application other than JMS
> ones then the activation-config in the MDB deployment descriptor will
> mean that the app server JNDI space is no longer used by MDBs. (For
> incoming messages.)
Thats correct.
>
> I take it that this applies to the genericjmsra as the app server does
> not specifically know that the messages are JMS ones.
Thats correct too. However the whole connector model for inbound
messaging has taken into account all (atleast most)
cases for JMS pluggability. So, using a resource adapter you can enable
pluggability with any JMS provider.
Now, a non-jms resource adapter also might send messages to MDBs. So,
from an appserver's perspective, it does not
know, what exactly is the meaning of activation config. It only serves
as a channel for passing those information to resource
adapter.
thanks,
Binod.
>
> Regards
>
>
>
> Donald
>
> Binod wrote:
>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>