Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [kapua-dev] Sharing our event proposal using transacted JMS events
The account creation operation needs to be idempotent, so that when the message is consumed on a retry it will just return success if account is already created and the event will be sent.

On Thu, Aug 24, 2017 at 2:02 PM, Morson, Stefano <stefano.morson@xxxxxxxxxxxx> wrote:

Ok but maybe I'm still not clear on this. Let's pick the account creation use case. The account is successfully created (committed to the database), then the send (or the message commit or something in between) fails:


- The retries will never succeed

- The code is not re-entrant


How should the client cope with this ?


Stefano
From: kapua-dev-bounces@xxxxxxxxxxx <kapua-dev-bounces@xxxxxxxxxxx> on behalf of Dejan Bosanac <dbosanac@xxxxxxxxxx>
Sent: Thursday, August 24, 2017 10:53:38 AM
To: kapua developer discussions
Subject: Re: [kapua-dev] Sharing our event proposal using transacted JMS events
 
Hi Stefano,

in that case JMS transaction is rolled back and the message is redelivered, so business logic will be executed again.

On Wed, Aug 23, 2017 at 3:31 PM, Morson, Stefano <stefano.morson@xxxxxxxxxxxx> wrote:

Hi,


I was looking at the code of the proof-of-concept for the Transacted JMS Events proposal, 

I just wanted to ask how the following should be managed:


- The business logic is executed successfully (the status has changed) but an error 

  occurs before or during the (message) commit.


Stefano


From: kapua-dev-bounces@xxxxxxxxxxx <kapua-dev-bounces@xxxxxxxxxxx> on behalf of Jens Reimann <jreimann@xxxxxxxxxx>
Sent: Tuesday, August 1, 2017 2:04:06 PM
To: kapua developer discussions
Subject: [kapua-dev] Sharing our event proposal using transacted JMS events
 
As discussed in the meeting on Monday I am sharing our proposal of using transacted JMS events for implementing the Kapua service event model.

The document is here:

    https://docs.google.com/document/d/1NRQl-6KPPK-3rNYOWWtwtKR2oc9_Hpc1u7jO1WURhlM

And the GitHub repository hosting the proof-of-concept:

   https://github.com/ctron/dtms-poc

As you can see, this proposal can be implemented in around 200 lines of code, using enterprise proven, standardized technologies. So this is nothing Kapua specific, but a plain and simple solution.

    Kudos go to Dejan Bosanac for proposing this approach.

Feel free to comment.

Cheers

Jens

--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev




--

_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev




--

Back to the top