This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
We recognise that this is a valid requirement. However it doesn't fit with our delivery plans for the next couple of years.
As a result we are declining this Idea. While declined the Idea can still be voted, and commented, upon.
Ah, just saw the comment from *2013* "Our intention is to provide formal support for any JTA-compliant implementation rather than specific named products. The timescale for this is undetermined.".... Ok, that's a little comforting, but it's from 2013 and i haven't been able to find any documentation about the best practices/instructions on how to incorporate v7 or higher JMS client with JTA-compliant implemtation.
As Calanais commented in https://stackoverflow.com/questions/31374595/standalone-spring-app-xa-transactions-with-ibm-mq-and-oracle-as-resources, please also consider including support for other major JTA TMs, eg. bitronix/Spring. We've been using Bitronix succesfully with WMQ (v6) in the past 4 years, until recently when trying to upgrade to higher version and suffered from IBM's removal of connection/session pooling out of the jms client (ref. http://www-01.ibm.com/support/docview.wss?uid=swg21665128).
I found at least 4 public complaints on stackoverflow caused by the removal of connection/session pooling out of jms client. There are also 2 RFE relevant to this change and are rejected. This change is pretty disturbing/disruptive to ibm mq customers using/depending on standalone java application with XA capability. According to JMS 2.0 spec ($6.2 pp.65), session is considered "a lightweight JMS object". Of course there might be different interpretation of "lightweight", but if creating a session requires open new socket (excluding sharedConversation from our discussion here, for high performance env i'm not sure how many people would use it.....), it should hardly be considered a "lightweight" jms object, and thus constitutes a clear violation of JMS spec.
What's more concerning is IBMMQ's position on what kind of support customers should expect for standalone java applications that use JTA compliant TM, which is the key point of this RFE if i understand correctly. If IBM MQ's strategy is to force/expect all customers using a full Application Server in order to get the benefit of (connection/)session pooling, then it doesn't satisfy our current requirement/usage. From http://www-01.ibm.com/support/docview.wss?uid=swg21665128, it's pretty much "good luck, you are on your own" to all standalone java app that also need XA.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Integration
Product - IBM MQ
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Connectivity and Integration
Product - IBM MQ
Our intention is to provide formal support for any JTA-compliant implementation rather than specific named products. The timescale for this is undetermined.