[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Further thoughts on issue BINDINGS-85
Simon: Let me analyze this from the other side i.e. what the reliability intents map to in terms of the DIMS binding config params. The Policy Framework defines 4 reliability intents. Here is what, in my understanding, they map to in terms of DIMS delivery mode: - atLeastOne: Persistent (this is more than what is requested but that may be OK) - atMostOnce: Non-Persistent - exactlyOnce (atLeastOnce+atMostOnce): Persistent - ordered: No appropriate config param. Supported by the runtime. So, two questions: - Simon, is this what you suggested? - Others, does this make sense? All the best, Ashok Simon Holdsworth wrote: > > The JMS 1.1 specification has the following to say about the > deliveryMode attribute (Section 4.7, Message Delivery Mode): > > A JMS provider must deliver a NON_PERSISTENT message /at-most-once. > /This means that it may lose the message, but it must not deliver it > twice. > A JMS provider must deliver a PERSISTENT message /once-and-only-once/. > This means a JMS provider failure must not cause it to be lost, and it > must not deliver it twice. > > So it seems quite reasonable to map the SCA atMostOnce intent to JMS > delivery mode of NON_PERSISTENT, and exactlyOnce to PERSISTENT, > although exactlyOnce is a profile intent that combines atMostOnce and > atLeastOnce, which would imply to me that atLeastOnce maps to a JMS > delivery mode of PERSISTENT. Although this does make life quite > difficult, because bindings that require exactlyOnce do also require > atLeastOnce. > > The only question I have left with regards to removing the > deliveryMode attribute as the resolution to this issue is whether we > should mandate in the JMS binding spec a specific mapping of these > intents to deliveryMode values, or remain silent and leave that > interpretation up to the SCA runtime. > > If we were to mandate the mapping, then the resolution to the issue > would be to remove the deliveryMode attribute, and replace the > following paragraph in section 5: > > Deployers/assemblers can configure NON_PERSISTENT for @JMSDeliveryMode > in order to provide higher performance with a decreased quality of > service. A binding.jms element configured in this way cannot satisfy > the "atLeastOnce" policy intent. The SCA runtime MUST raise an error > for this invalid combination at deployment time. > > with: > > The JMS delivery mode used to send messages from a JMS binding > instance which requires the atMostOnce intent and not the atLeastOnce > intent MUST be NON_PERSISTENT [BJM5000X] > The JMS delivery mode used to send messages from a JMS binding > instance which requires the atLeastOnce intent MUST be PERSISTENT > [BJM5000Y] > > Given the deliveryMode default is PERSISTENT, we could also say: > > The JMS delivery mode used to send messages from a JMS binding > instance which does not require either of these intents MUST be > PERSISTENT [BJM5000Z] > > In fact these could all be collapsed into a single statement: > > The JMS delivery mode used to send messages from a JMS binding > instance MUST be NON_PERSISTENT if it requires the atMostOnce intent > and not the atLeastOnce intent, and PERSISTENT otherwise [BJM5000X] > > Comments? > > Regards, Simon > > Simon Holdsworth > STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair > MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898 > Internet - Simon_Holdsworth@uk.ibm.com > > > ------------------------------------------------------------------------ > > / > / > > /Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]