I think you're both in violent agreement. May I offer the 1.1 transactedOneWay policy as common terminology that I think you're both referring to? Might help clear up the conversation.
On 10/26/2011 9:58 AM, Jim Marino wrote:
Hi Sanjay,
In my view, Reliable Messaging with local transactions have different semantics than a send or receive in the context of an XA transaction. Namely, they won't provide the same send or receive guarantees I outlined below. Conversely, Reliable Messaging may provide certain guarantees that transactional send and receive don't.
Could you elaborate as to why you may think the following are potentially not relevant to eventing as opposed to messaging:
1. "Send only if all associate work completes successfully".
2. "Only acknowledge receive if all associated work completes successfully; otherwise retry".
Also, just to be clear on these scenarios, there is no transactional context propagation between sender and receiver and hence no "distributed transaction" in the sense of remote objects.
Jim
On Oct 26, 2011, at 6:40 PM, Patil, Sanjay wrote:
I think this is a classic scenario of using reliable messaging with local transactions at the two endpoints (sending and receiving) as an alternative solution for using distributed transaction across the endpoints.
I would also note that this scenario pertains more to Messaging and not so much to Eventing in its general sense (as in sca eventing).
Just my 2c.
Sanjay
---------------------
Sent from my BlackBerry Wireless Handheld
----- Original Message -----
From: Jim Marino [mailto:jim.marino@gmail.com]
Sent: Wednesday, October 26, 2011 12:23 PM
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Subject: Re: [sca-assembly] Action re. SCA Assembly Issue 233
Sure, here are two:
1. Producer needs to broadcast an event and perform other work in the context of a global (XA) transaction. Broadcasting the event and doing the other work are performed by XA resource participants according to 2PC. Basically, "send only if all associate work completes successfully".
2. Consumer needs to receive an event and perform some work in the context of a global (XA) transaction. Receiving the event and performing the work are performed by XA resource participants according to 2PC. Basically, "only acknowledge receive if all associated work completes successfully; otherwise retry or do something else".
Note there is no coupling in terms of transaction context propagation between producer and consumer; the coupling is between the producer and eventing fabric/messaging and consumer and eventing fabric/messaging layers respectively.
HTH
Jim
On Oct 26, 2011, at 5:53 PM, ashok malhotra wrote:
Hi Jim:
I'm happy to reconsider. Can you send us brief usecases?
All the best, Ashok
On 10/26/2011 8:40 AM, Jim Marino wrote:
Hi Ashok,
Can you elaborate the reasoning behind that? It seems to me transactions (at least things like transactional receive/notification) are very relevant to eventing. We are using them in a number of our applications with Fabric3.
Jim
On Oct 26, 2011, at 4:50 PM, ashok malhotra wrote:
Hi Jim:
There is one line that says Transaction Intents do not apply to eventing.
All the best, Ashok
On 10/26/2011 7:47 AM, Jim Marino wrote:
Hi Ashok,
What about transaction intents? I didn't see them in the document.
Thanks,
Jim
On Oct 26, 2011, at 4:38 PM, ashok malhotra wrote:
See the attached doc as a first cut at which SCA Policy intents apply to eventing.
Needs discussion.
--
All the best, Ashok
<Which SCA Policy Intents Apply to Eventing.doc>
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org