[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Further thoughts on issue BINDINGS-85
I also had a longish discussion with one of our JMS experts and he told me exactly what Eric's experts did: This is a little bit more complex. Whether or not the JMS session is a transacted session affects the delivery mode, the ack mode also has an effect and various vendors have defined all kinds of extensions that complicate this even further. We have 2 different JMS implementation: one that requires a DB and one that doesn't (but still uses filesys-based stable-storage) and the behavior can be slightly different depending on what other options/extensions are in play. -Anish -- Eric Johnson wrote: > I also like Simon's text, but for a different reason. > > I just checked with one of our JMS experts, and he pointed out to me > that PERSISTENT and NON_PERSISTENT have little to do with the policy > notions of atMostOnce or atLeastOnce. Instead, what matters is the > particular use of the JMS APIs. Are transactions being used? What kind > of acknowledgment mode is in play? Does the particular JMS vendor > provide any extensions that might be used to satisfy the policies? > > So I concur - policy settings shouldn't map to a specific delivery mode > setting, and the proposed text about flagging a conflict between > delivery mode and policy seems appropriate to me. > > -Eric. > > David Booz wrote: >> >> Simon, >> >> I don't like the idea of expanding the meaning of any of the >> reliability intents beyond their current numerical meaning. It's >> important (though not required) for intents to have a consistent >> meaning across bindings to enable binding replace-ability within SCA >> as much as possible. Therefore, given your concern that NON_PERSISTENT >> might encompass an implied non-functional requirement for a high speed >> transport, then I would tend to favor the latest solution that you >> just proposed. >> >> Dave Booz >> STSM, BPM and SCA Architecture >> Co-Chair OASIS SCA-Policy TC and SCA-J TC >> "Distributed objects first, then world hunger" >> Poughkeepsie, NY (845)-435-6093 or 8-295-6093 >> e-mail:booz@us.ibm.com >> >> Inactive hide details for Simon Holdsworth ---09/11/2009 06:05:18 >> AM---Ashok, Comments inline.Simon Holdsworth ---09/11/2009 06:05:18 >> AM---Ashok, Comments inline. >> >> >> From: >> Simon Holdsworth <simon_holdsworth@uk.ibm.com> >> >> To: >> sca-bindings@lists.oasis-open.org >> >> Date: >> 09/11/2009 06:05 AM >> >> Subject: >> Re: [sca-bindings] Further thoughts on issue BINDINGS-85 >> >> ------------------------------------------------------------------------ >> >> >> >> >> Ashok, >> >> Comments inline. >> >> ashok malhotra <ashok.malhotra@oracle.com> wrote on 10/09/2009 18:41:27: >> >> > 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? >> >> Yes, that's what I was suggesting. The problem with this relationship >> is that it is asymmetric - you can't say "atMostOnce implies delivery >> mode is Non-Persistent" because if exactlyOnce is required, it also >> requires atMostOnce, and in that case delivery mode is Persistent. >> >> The problem for me is that while exactlyOnce satisfies the abstract >> numerical requirement of atMostOnce, the cost of providing the >> additional restriction of atLeastOnce doesn't satisfy the (in my >> opinion expected) non-functional requirement of atMostOnce which is >> provision of a high performance lightweight message interaction. I >> think that would be the reason the intent would be selected by people >> familiar with JMS, expecting to use it to achieve a NON_PERSISTENT >> deliveryMode for their messages sent by the JMS binding. >> >> Another way of saying this is that I don't believe >> deliveryMode=PERSISENT satisfies the requirements of >> deliveryMode=NON_PERSISTENT so I don't believe we can say that the JMS >> binding always satisfies atLeastOnce, which I think Anish was >> questioning. >> >> My take on this issue is that if we can't come up with a clear >> relationship between the intents and delivery modes that we can >> explain in the JMS binding so that JMS-savvy people know what to >> expect from their JMS binding, or if we retain the purely numerical >> interpretation of the reliability intents, then we should retain the >> current deliveryMode attribute and resolve the issue by weakening the >> current statement of incompatibility along the lines: >> >> Deployers/assemblers can configure NON_PERSISTENT for @deliveryMode in >> order to provide higher performance with a decreased quality of >> service. A binding.jms element configured in this way might not be >> able to satisfy the "atLeastOnce" policy intent. The SCA runtime MUST >> raise an error at deployment time if it is unable to support the >> combination of @deliveryMode=NON_PERSISTENT and the "atLeastOnce" >> intent [BJM5000X]. >> >> > - 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/ >> > > >> > > >> > > >> > > >> > > >> > > >> >> >> >> ------------------------------------------------------------------------ >> / >> / >> >> /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/ >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> / >> / >> >> /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]