activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <>
Subject Re: NMS API design question regarding AckMode
Date Thu, 29 May 2008 04:47:18 GMT
Hi Mark,

I like the idea of having providers extend the session modes to what makes
sense for them.  For instance, MSMQ may ignore transactional, but have some
additional acknowledgment mode.  However, what do you propose as a solution
such that provider's individual extensions to the acknowledgment mode do not
"pollute" the global API space?  I like your suggestion of having a loose
and flexible API, and I would think that an acknowledgement mode as a
string, versus an enumeration, would be the "loosest".  But that may not be
the best way to go.

Changing to a string might work.  The current enumeration could be changed
to readonly strings.  This way providers would be free to support custom
acknowledgment modes through the single parameter.  Thoughts?


On Wed, May 28, 2008 at 7:24 PM, Mark Pollack <>

> Hi,
> I'm digging into the NMS API a bit more as I plan to release NMS support in
> Spring.NET in the coming months (which James had a hand in as well) and I
> have a question regarding the AcknowledgementMode enum.  The current values
> CLIENT_ACKNOWLEDGE) and an additional one Transactional.
> Vendors typically provide additional ack modes for increased performance,
> TIBCO EMS is the case I'm familiar with which also has
> ExplicitClientAcknowledge, ExplicitClientDupsOkAcknowledge, and
> NoAcknowledge.
> At the moment the NMS API can't support these modes, making it a
> lowest-common denominator solution, something I feel that must be avoided
> if
> it is to gain widespread use.  I've had a similar experience writing a
> database wrapper class for ADO.NET and the use of vendor specific enums
> for
> data types.  I ended up leaving the API very 'loose', i.e. method signature
> just has 'Enum' in it and internally implementations can check to see if it
> makes sense for them.  This has worked out well as far as I can tell.
> Is it possible to follow the same approach in this case?
> Cheers
> Mark

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message