activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Pollack" <>
Subject RE: NMS API design question regarding AckMode
Date Mon, 09 Jun 2008 19:27:49 GMT

Just a ping to see if we can get closure on an approach...


-----Original Message-----
From: Mark Pollack [] 
Sent: Thursday, May 29, 2008 10:09 AM
To: ''
Subject: RE: NMS API design question regarding AckMode


My suggestion is to have the base enumeration class, System.Enum, be used.
I suspect that all .NET messaging providers have used enums for ack modes
and if they didn't, the NMS implementation for that provider could supply

In the case of the EMS binding, this would read


This seems more natural than using a literal string.  All the general
arguments of enum vs. string apply here.

I used this approach with System.Data.DbType, the base enum for data types
in ADO.NET.  All ADO.NET providers have their own custom enum (for
'advanced' data types like xml, arrays etc.)  This has seemed to work out
well, at least no complaints.


-----Original Message-----
From: Rob Davies [] 
Sent: Thursday, May 29, 2008 2:32 AM
Subject: Re: NMS API design question regarding AckMode

+1 on Strings

On 29 May 2008, at 05:47, Jim Gomes wrote:

> 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?
> Regards,
> Jim
> On Wed, May 28, 2008 at 7:24 PM, Mark Pollack
> >
> wrote:
>> 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

View raw message