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

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

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