Nigel,
I like your proposal to merge Session and MessageProducer into a MessagingContext. And in an EE setting, it would be trivial to inject that.
In your proposal it's not perfectly clear that also in the SE setting, it should be possible to abbreviate connectionFactory.createConnection().createMessagingContext() as connectionFactory.createMessagingContext(), right?
On 11.11.2011, at 18:41, Nigel Deakin wrote:
On 11/11/2011 17:04, Clebert Suconic wrote:
On Fri, Nov 11, 2011 at 10:59 AM, Nigel Deakin <nigel.deakin_at_oracle.com<mailto:nigel.deakin_at_oracle.com>> wrote:
On 11/11/2011 16:08, Clebert Suconic wrote:
I'm not sure I like this next proposal... so, another brain storm...
which one don't you like?
This one I"m making now...
What if we had 4 basic objects?
NewConnectionFactory
NewConsumer.... created with cf.createConsumer(queue);
NewProducer .... created with cf.createConsumer(queue);
NewRequestResponse... created with cf.createRequestResponse(queueSend, queueConsume); That would be a Consumer/Producer mixed in a single object for the case of the request/response.
Can you explain what you mean by "request/response" here? Are you describing the requestor application or the responder application? Are you thinking of EE or SE?
I'm thinking of any use case where Consumer and Producer need to be in the same Context.
Ah yes. That would be the responder part of request/response. I agree it's a common use case, but I think we should be aiming at a API which is really simple and doesn't need special API to support such important cases.
I'm thinking of SE. For EE we can just rely on XA.
As I mentioned, if we want to avoid two-phase commit when using separate sessions the JMS provider needs to support joining of resources, which is not currently mandatory
-----
I still like my own proposal for:
a. Merging Session and Connection (easy for Java EE, a major restriction for Java SE)
b. Removing the need to create a MessageProducer for anything
c. Removing the need to create a MessageConsumer when using a MessageListener (Java SE only)
Which leaves us with the following main interfaces:
1. ConnectionFactory
2. NewConnection (perhaps MessagingContext is a better name) - This is a merged connection, session and anonymous producer, which also supports setMessageListener() where allowed.
3. SyncConsumer
I think that's pretty simple.
Perhaps we can address the Java SE case by formalising two separate ways to create MessagingContext objects, one for EE and one for SE:
In EE you call connectionFactory.createContext() to create a MessagingContext.
In SE you call connectionFactory.createConnection() as at present, and then call Connection.createMessagingContext() to create one or more MessagingContext objects which use the same underlying connection. The rest of the API would be the same.
I think I'll write this all up over the next week or so. If you'd like to write up your own ideas in a bit more detail please do. I think it'll be easier for us to review each other's ideas then.
Have a good weekend.
Nigel
Anything different than that would have to go through JTA. (Merge on JTA would take care of placing everything as part of the same TX)
No more need for Contexts on that case.
As I wrote earlier, I don't think we should assume that the RM implements isSameRM() to return true.
Just a brain storm..I'm not 100% sure about if I like it or not.
I don't think we're there yet.
I still like my own proposal from yesterday. Can you take a look and let me know what you think? Would you like me to explain it better?
Nigel