RE: [sca-assembly] Action re. SCA Assembly Issue 233

["Patil, Sanjay" <sanjay.patil@sap.com>]

Hi Jim,


The idea of acknowledging the receipt of an event (in your item #2) makes me relate your scenario more with reliable messaging. For general eventing, the logic at the producer of events should be decoupled from the consumption of the events. Would you agree?

I can see how XA transactions could be utilized on the sender side for modeling the send-an-event-iff-certain-work-completes semantics. However, to me, this model sounds like an internal detail of the event producer. I don't see how declaring the transactional intent on the event producer would be useful (to any other SCA components, etc). If the purpose of declaring the transactional intent is only to instruct the infrastructure, then I guess that is a somewhat narrow use case, since we would be assuming this feature to work only for a specific kind of eventing infrastructure (one which can be an XA resource). 

However, since I do not know the details of your actual use case, I might be making some assumptions. So please feel free to correct me ...

Sanjay

-----Original Message-----
From: sca-assembly@lists.oasis-open.org [mailto:sca-assembly@lists.oasis-open.org] On Behalf Of Jim Marino
Sent: Wednesday, October 26, 2011 9:58 AM
To: OASIS Assembly
Subject: Re: [sca-assembly] Action re. SCA Assembly Issue 233

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