OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


+1 if you're talking about the transactedOneWay use cases.

What I'm left wondering, though, is Is anyone proposing any relevance of transactions whose scope encompasses at least one producer AND at least one consumer?  I'm hoping not.

Danny

On 10/26/2011 2:38 PM, Jim Marino wrote:
Hi Danny,

You are right I am talking about transactedOneWay in the context of a gloabal (XA) transaction. I'm not sure I and Sanjay are in agreement, though, since I think that combination of intents mean something different than local transaction + reliable messaging. For example, local transaction + reliable messaging cannot guarantee the following will happen, while transactedOneWay + XA do:

- Send event only if associated work is guaranteed to complete
- Acknowledge receipt only if associated work is guaranteed to complete

These differences aside, my main concern is to avoid coming to the conclusion that transactions are irrelevant to eventing.

Jim
  
On Oct 26, 2011, at 8:34 PM, Danny van der Rijn wrote:

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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]