activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: NMS API design question regarding AckMode
Date Thu, 29 May 2008 06:32:25 GMT
+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 <mark.pollack@springsource.com 
> >
> 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
>> are those in the JMS spec (DUPS_OK_ACKNOWLEDGE, AUTO_ACKNOWLEDGE,
>> 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
>>
>>
>>
>>


Mime
View raw message