[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] NEW ISSUE 7: JMS bindingType and ordered intent
Hi Michael, Well, that guarantee & semantics reminds me of BEA's Unit-Of-Order feature :) , but that would require from the binding implementation to mark the two messages (by a property ?) while sending in other to indicate which were generated by one instance, are in one "order group" and need to be delivered sequentially in the receiver. Personally I am fine with such approach. You have raised the interesting question for multiple consumers (i.e. components) for one queue, that question is not covered in the JMS spec. But I am not sure whether that should be connected with the ordered intent. Maybe that should be modeled by a new set of intents -- "round-robin", "always the first receives, many can subscribe", "all but the first receive exception if trying to subscribe", etc. Do you want to raise a new issue ? Best Regards Peter -----Original Message----- From: Michael Rowley [mailto:mrowley@bea.com] Sent: Monday, 8. October 2007 18:58 To: Peshev, Peter Cc: sca-bindings@lists.oasis-open.org Subject: RE: [sca-bindings] NEW ISSUE 7: JMS bindingType and ordered intent I agree that this needs to be clarified. There are many possible semantics that could be associated with the ordered intent. It also could imply routing decisions -- when there are multiple consumers pulling off the same queue, do you want 2 messages that are sent with a strict ordering to be handled by the same consumer? I believe that the ordering semantic should be quite weak, so that it can apply to many possible mechanisms. Here is a rough proposal: Under the following conditions: - Two messages are sent through a single reference. - The sending component knows the order in which the messages were sent (i.e. they weren't sent from parallel threads -- this condition needs to be formalized). - The two messages are both received by a component's service, and have not been received in parallel threads (again this needs to be formalized, or we may want to consider saying that the messages must not be received in parallel). Guarantee: - The two messages will arrive at the receiving component in the same order in which they were sent. Naturally, if the definition is in terms of any two messages, the complete sequence will be ordered by induction. Michael -----Original Message----- From: Eric Johnson [mailto:eric@tibco.com] Sent: Friday, October 05, 2007 12:44 PM To: Peshev, Peter Cc: sca-bindings@lists.oasis-open.org Subject: [sca-bindings] NEW ISSUE 7: JMS bindingType and ordered intent Logged as: http://www.osoa.org/jira/browse/BINDINGS-7 -Eric. Peshev, Peter wrote: > TARGET: > JMS Binding Specification Version 1.1, Working Draft 25 September 2007 > > > DESCRIPTION: > > The current bindingType of the jms is defined as : > > <bindingType type="binding.jms" alwaysProvides="jms" > mayProvide="atLeastOnce atMostOnce ordered conversation"/> > > A guidance for the implementation could be made for the ordered intent > and what does it mean in the JMS case. > > If it is provided by the assembler, it is especially interesting what > happens if there are several instances of service consumers sending JMS > messages in concurrent. Does the intent means that the messages are > "ordered" within the instance that produced them - i.e. each service > consumer instance is having a separate JMS session and in that case the > ordering is guaranteed by the semantics of the JMS session. > > Or there is a global ordering within all the concurrent service > consumers ? I.e. there is a global synchronization in the JVM for the > whole wire, and there is a single JMS session behind it. > > Of course if there is no such "ordered" intent, the binding is free to > do whatever it wants - a pool of JMS sessions, each time opening new > one, etc. > > PROPOSED SOLUTION > Include clarification in the spec > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]