Camel
  1. Camel
  2. CAMEL-123

add an 'on commit / on rollback' hook so that non-transactional components can do things like delete files when the processing has completed

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 2.0-M2
    • Component/s: camel-core
    • Labels:
      None

      Description

      e.g. file / FTP should only delete the file after successful processing has occurred etc

        Issue Links

          Activity

          Hide
          james strachan added a comment -

          have added a UnitOfWork object on an Exchange which can act as the registration point for onComplete / onFailure callbacks - it just needs to be wired into the sync/async processing changes Hiram made yesterday

          Show
          james strachan added a comment - have added a UnitOfWork object on an Exchange which can act as the registration point for onComplete / onFailure callbacks - it just needs to be wired into the sync/async processing changes Hiram made yesterday
          Hide
          Claus Ibsen added a comment -

          James any update/status on this? Is there some work pending?

          Show
          Claus Ibsen added a comment - James any update/status on this? Is there some work pending?
          Hide
          Claus Ibsen added a comment -

          The File components could benefit from this so they will hook into UOW and get a onComplete or onFailure callbacks.

          These components handle it themself today using try .. catch logic.

          I might as well take on this one and use the file component as use-case. For starters the API can be exposed internally/spi and later we can consider some nice DSL supports so you can attach custom code to be invoked.

          Show
          Claus Ibsen added a comment - The File components could benefit from this so they will hook into UOW and get a onComplete or onFailure callbacks. These components handle it themself today using try .. catch logic. I might as well take on this one and use the file component as use-case. For starters the API can be exposed internally/spi and later we can consider some nice DSL supports so you can attach custom code to be invoked.
          Hide
          Claus Ibsen added a comment -

          UnitOfWork is only weaven into the route if you use the route builder.

          For manual code such as creating a consumer from an endpoint will not inject the UoW

          Show
          Claus Ibsen added a comment - UnitOfWork is only weaven into the route if you use the route builder. For manual code such as creating a consumer from an endpoint will not inject the UoW
          Hide
          Claus Ibsen added a comment -

          We got a catch-22 situation

          UnitOfWorkProcessor set up the add/remove synchronzation callbacks but they are lazy created just before the Exchange is processed.
          So in another component/consumer component/producer you can not add the synchronization before its processed.

          But you need to use the async processor and do it in the callback done method.

          Need to look into this some more. The idea is also to expose some nice methods in the DSL so end users can add their own custom processing, such as being able to send an email, log or whatever an exchange is done/failed.

          Show
          Claus Ibsen added a comment - We got a catch-22 situation UnitOfWorkProcessor set up the add/remove synchronzation callbacks but they are lazy created just before the Exchange is processed. So in another component/consumer component/producer you can not add the synchronization before its processed. But you need to use the async processor and do it in the callback done method. Need to look into this some more. The idea is also to expose some nice methods in the DSL so end users can add their own custom processing, such as being able to send an email, log or whatever an exchange is done/failed.
          Hide
          Claus Ibsen added a comment -

          A work in progress patch.

          We need to step back and rethink this one. James have some good ideas.

          Show
          Claus Ibsen added a comment - A work in progress patch. We need to step back and rethink this one. James have some good ideas.
          Hide
          Claus Ibsen added a comment -

          [13:22] <jstrachan> cibsen: with all this consumer v route v UOW; we maybe need a review of all that code really - as when we allow for routes to be started/stopped as independent things it might change things a bit
          [13:23] <cibsen> yeah
          [13:24] <cibsen> there is a gremlin lying there waiting when starting/stopping routes is more dynamic
          [13:24] <cibsen> I will park my work and attach a patch to the ticket
          [13:26] <jstrachan> yeah
          [13:26] <jstrachan> might have a big impact when we try add that
          [13:26] <jstrachan> it'd be great if we can keep all the big impacts inside the core common impl of camel rather than having component/endpoint developers having to worry about it
          [13:29] <cibsen> +1
          [13:29] <cibsen> yeah I wanted the UoW stuff for components as well so they can register custom code for clean up
          [13:29] <jstrachan> yeah!
          [13:29] <jstrachan> however that works - we need a nice simple API the component developers can use
          [13:30] <jstrachan> then we can tinker under the covers to figure out how it works
          [13:30] <jstrachan> (whether using real spring transactions, or UOW or whatever)
          [13:30] <jstrachan> maybe we should just use spring transactions for example?
          [13:30] <cibsen> I also thoght that we needed a nice DSL in the route: from.onComplete(process).to(zzz)
          [13:30] <jstrachan> and just kinda make transactions look like a transaction manager?
          [13:30] <jstrachan> though then there's the transaction context propogating threads issue etc
          [13:30] <jstrachan> yeah
          [13:31] <jstrachan> we might also want to be able to start/stop routes by ID too
          [13:31] <cibsen> yeah i think we should stick with Spring TX
          [13:31] <jstrachan> yeah
          [13:31] <cibsen> its to comple to roll out your own
          [13:31] <jstrachan> lets do it
          [13:31] <jstrachan> yeah
          [13:31] <jstrachan> then we'd just need a file transaction manager
          [13:31] <jstrachan> or some kinda 'simple local transaction manager' for non-tx resources

          Show
          Claus Ibsen added a comment - [13:22] <jstrachan> cibsen: with all this consumer v route v UOW; we maybe need a review of all that code really - as when we allow for routes to be started/stopped as independent things it might change things a bit [13:23] <cibsen> yeah [13:24] <cibsen> there is a gremlin lying there waiting when starting/stopping routes is more dynamic [13:24] <cibsen> I will park my work and attach a patch to the ticket [13:26] <jstrachan> yeah [13:26] <jstrachan> might have a big impact when we try add that [13:26] <jstrachan> it'd be great if we can keep all the big impacts inside the core common impl of camel rather than having component/endpoint developers having to worry about it [13:29] <cibsen> +1 [13:29] <cibsen> yeah I wanted the UoW stuff for components as well so they can register custom code for clean up [13:29] <jstrachan> yeah! [13:29] <jstrachan> however that works - we need a nice simple API the component developers can use [13:30] <jstrachan> then we can tinker under the covers to figure out how it works [13:30] <jstrachan> (whether using real spring transactions, or UOW or whatever) [13:30] <jstrachan> maybe we should just use spring transactions for example? [13:30] <cibsen> I also thoght that we needed a nice DSL in the route: from .onComplete(process).to(zzz) [13:30] <jstrachan> and just kinda make transactions look like a transaction manager? [13:30] <jstrachan> though then there's the transaction context propogating threads issue etc [13:30] <jstrachan> yeah [13:31] <jstrachan> we might also want to be able to start/stop routes by ID too [13:31] <cibsen> yeah i think we should stick with Spring TX [13:31] <jstrachan> yeah [13:31] <cibsen> its to comple to roll out your own [13:31] <jstrachan> lets do it [13:31] <jstrachan> yeah [13:31] <jstrachan> then we'd just need a file transaction manager [13:31] <jstrachan> or some kinda 'simple local transaction manager' for non-tx resources
          Hide
          Claus Ibsen added a comment -

          We need a bit more time on this one, and I want to narrow down on a milestone build of Camel 2.0

          Show
          Claus Ibsen added a comment - We need a bit more time on this one, and I want to narrow down on a milestone build of Camel 2.0
          Hide
          Claus Ibsen added a comment -

          CAMEL-1604 implements this feature

          Show
          Claus Ibsen added a comment - CAMEL-1604 implements this feature
          Hide
          Claus Ibsen added a comment -

          Closing all 2.0M2 tickets

          Show
          Claus Ibsen added a comment - Closing all 2.0M2 tickets

            People

            • Assignee:
              Claus Ibsen
              Reporter:
              james strachan
            • Votes:
              3 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development