If XA is used as a XA Transaction Manager using Java MQ classes, not JTA, the Java application and the WMQ, both need to reside on the same host machine. I have been told this is because shared memory is used as Inter Process Communication mechanism.
If we use deploy WMQ in a docker container and keep our Java application in another docker container, both on the same host, will we be able to use the WMQ as a XA coordinator?
Will we have to use certain special configuration of the container to get it working?
Regards,
Yash
Related
I am trying to run a java application in bindings mode in IBM MQ docker image, but i am not able to find a proper resource for the same. Do IBM MQ has support for bindings mode in IBM MQ Docker image?
Yes with version limits. If the application is in the same container as the queue manager you can use local bindings to connect them. If they are not then as long as you are using MQ version 9.0.3 or above you can share container namespaces to run the application in a different container than the queue manager.
Source From this knowledge center page on IBM MQ Container Support:
You can use namespacing to share the namespaces of the container for the queue manager with other containers, in order to locally bind applications to a queue manager running in separate containers. For more information, see Running local binding applications in separate containers.
This article indicates that if MQ has to be used as a Transaction Manager, the application has to compulsorily use Bindings mode.
http://www.ibm.com/developerworks/websphere/library/techarticles/0601_ritchie/0601_ritchie.html
Bindings mode also means that the MQ Server and the application both have to be on the same host because it uses JNI.
My question is, what is the fundamental reason behind this requirement? Why can't MQ Manager work like JBOSS which can reside on any host and take requests for managing distributed transactions?
What prevents WMQ from supporting client connection for distributed transactions?
Thanks,
Yash
That article is very old, it was from 2006, for a long time now MQ clients that are located remote from a queue manager have been able to use XA transactions.
MQ supports XA with JMS when using a supported transaction manager within a JEE container
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q032590_.htm?lang=en
I am new to MDB, so my questions may sound simple.
I implemented an MDB( serving as a Consumer ) using JDeveloper 11.1.7 and built a JAR file using deployment functionality. Now I need to deploy it to WebLogic 10.3 app server. I have several questions:
1) Should I deploy it as a library or as an application?
2) After I successfully deploy and it's in the "RUNNING" mode I assume it should be listening to the particular Queue I specified as a Resource in my MDB implementation. Is that correct?
3) When implementing an MDB all the examples only specify the "destination" but not the "ConnectionFactory". How does it know where to connect to?
Should I deploy it as a library or as an application?
Deploy as an application since the MDB will likely contain business logic specific to the app.
After I successfully deploy and it's in the "RUNNING" mode I assume it
should be listening to the particular Queue I specified as a Resource
in my MDB implementation. Is that correct?
Yes, if your JMS provider is local, specify the name bound in the local JNDI tree for the destination using destination-jndi-name.
When implementing an MDB all the examples only specify the
"destination" but not the "ConnectionFactory". How does it know where
to connect to?
If the MDB is consuming messages from the local WebLogic JMS provider, the container manages configuration for the connections and sessions automatically, so don't set provider-url, initial-context-factory, or connection-factory-jndi-name, unless you have a custom factory to use.
Refer to WebLogic 10.3 documentation for details:
I am developing a service for JMS messaging using IBM WMQ version 7.5 as Message oriented middleware. I am in a dilemma. The IBM specification says to use WebSphere MQ JMS API in JAVA EE environment. My sender and receivers will be in remote JBoss deployments. IBM provides a resource adapter to connect via JCA. This connection requires static administration of components such as Queue managers, queue channels, queue names.
Is JCA the best I can do ? Is there any other way where I can dynamically create the queues provided that I know other configuration details ? There will be multiple applications using this setup running on their own servers. If I use JCA, all have to make their own configurations. Can I make dynamic configurations ?
Typically within the application server environment resources would be created in some JNDI context. These would be Connection Factories and Destinations.
Depending on the app server, it may be possible to share this configuration across a network of individual servers. So typically there would be some set of static definitions.
However within say a servlet the MQConnectionFactory can be dynamically created.
In all cases the backing WMQ Resources do need to exist; though it is possible to send administrative command messages to WMQ to create queues and do other admin. The only exception is topics, accessing a topic string brings it into existence. Though this has default security properties that you might not want.
I am trying to configure clustered JMS on Weblogic 10.3.4.
I have a 4 node cluster plus my AdminServer already configured. I also have my JMS already configured and targeted to AdminServer. From reading the Weblogic documentation, I am not clear as how to cluster the JMS server. Could someone please explain how?
There is no 'clustered JMS server'. There are WebLogic clusters, the Admin Server & Managed Servers and then JMS Servers. JMS Servers are a configuration construct within a Managed Server.
In order to cluster JMS in WebLogic each managed server in the cluster needs a JMS server. Then, when you create JMS resources you can either use default targeting or subdeployments. If you use default targeting then it will implicitly target the resource to the JMS server for each managed server in the cluster. If you have more than one JMS server per managed server, the behavior can be different, but you likely don't need that. Alternatively, you can use subdeployments to target specific managed servers or JMS servers, but not likely needed for your purposes.