Why create transaction in Event?

[叶双明]

Hi all:

After update ofbiz to 13.07.03, our system was Unstable. At last, I found
the cause was The transaction created in Event, introduced in revision
1,740,632.
And found https://issues.apache.org/jira/browse/OFBIZ-6808.
But I doubt whether it is good to do this.

In my opinion:

1. It would make more long-running transaction.
    For example, there was a event which call three services, the three
services has their own transaction before the change, but now there is one
big transaction for the event and three services, of course the transaction
would run longer time.

2. It would make a lots of transaction run longer time.
    Almost all event would do something else after call service, for
example, convert the result from service to JSON format, but the conversion
not need transaction!

3. It makes it difficult to manage transactions between services and events.
    For example, there was a event:

    public String createOrder() {

        //some business process here... and define serviceCtx

        def results = dispatcher.runSync("createOrder", serviceCtx)

        //some business process here... and return success or error at last

    }

    after call createOrder service success, i want to fire a jms
service(call it jmsIndexOrder) to index the order in Elasticsearch。
    I use secas before the change, everything work well.

    <eca service=“createOrder” event="return">
        <action service="jmsIndexOrder" mode="sync"/>
    </eca>


    but now i don't know where ant how to call jmsIndexOrder. :(


--
叶双明

[Scott Gray-3]

You can leave your code mostly the same, but just require a new transaction
for createOrder, you'll see the option available in the runSync overloaded
methods.

I've been working with an older version of OFBiz for the last few years so
I wasn't aware of this change, but I believe it is better than what we had
before.  The primary purpose of an event in OFBiz is to perform some sort
of action, and it is very easy for developers to unwittingly directly write
to the database inside an event.  Obviously this is problematic when the
updates aren't wrapped in a transaction.  Virtually everything else in
OFBiz automatically begins a transaction (services, simple methods,
screens, etc.) and I think it was a good idea for the sake of consistency
to have the same behavior with events.

The behavioral change between versions is regrettable, but also unavoidable
if we want to progress.

Regards
Scott

On 26 July 2016 at 19:02, 叶双明 <[hidden email]> wrote:

> Hi all:
>
> After update ofbiz to 13.07.03, our system was Unstable. At last, I found
> the cause was The transaction created in Event, introduced in revision
> 1,740,632.
> And found https://issues.apache.org/jira/browse/OFBIZ-6808.
> But I doubt whether it is good to do this.
>
> In my opinion:
>
> 1. It would make more long-running transaction.
>     For example, there was a event which call three services, the three
> services has their own transaction before the change, but now there is one
> big transaction for the event and three services, of course the transaction
> would run longer time.
>
> 2. It would make a lots of transaction run longer time.
>     Almost all event would do something else after call service, for
> example, convert the result from service to JSON format, but the conversion
> not need transaction!
>
> 3. It makes it difficult to manage transactions between services and
> events.
>     For example, there was a event:
>
>     public String createOrder() {
>
>         //some business process here... and define serviceCtx
>
>         def results = dispatcher.runSync("createOrder", serviceCtx)
>
>         //some business process here... and return success or error at last
>
>     }
>
>     after call createOrder service success, i want to fire a jms
> service(call it jmsIndexOrder) to index the order in Elasticsearch。
>     I use secas before the change, everything work well.
>
>     <eca service=“createOrder” event="return">
>         <action service="jmsIndexOrder" mode="sync"/>
>     </eca>
>
>
>     but now i don't know where ant how to call jmsIndexOrder. :(
>
>
> --
> 叶双明
>

[叶双明]

Sorry, my code is base on newest in branch release13.07, after release
13.07.03.

2016-07-26 15:02 GMT+08:00 叶双明 <[hidden email]>:

> Hi all:
>
> After update ofbiz to 13.07.03, our system was Unstable. At last, I found
> the cause was The transaction created in Event, introduced in revision 1,740,632.
> And found https://issues.apache.org/jira/browse/OFBIZ-6808.
> But I doubt whether it is good to do this.
>
> In my opinion:
>
> 1. It would make more long-running transaction.
>     For example, there was a event which call three services, the three
> services has their own transaction before the change, but now there is one
> big transaction for the event and three services, of course the transaction
> would run longer time.
>
> 2. It would make a lots of transaction run longer time.
>     Almost all event would do something else after call service, for
> example, convert the result from service to JSON format, but the conversion
> not need transaction!
>
> 3. It makes it difficult to manage transactions between services and
> events.
>     For example, there was a event:
>
>     public String createOrder() {
>
>         //some business process here... and define serviceCtx
>
>         def results = dispatcher.runSync("createOrder", serviceCtx)
>
>         //some business process here... and return success or error at last
>
>     }
>
>     after call createOrder service success, i want to fire a jms
> service(call it jmsIndexOrder) to index the order in Elasticsearch。
>     I use secas before the change, everything work well.
>
>     <eca service=“createOrder” event="return">
>         <action service="jmsIndexOrder" mode="sync"/>
>     </eca>
>
>
>     but now i don't know where ant how to call jmsIndexOrder. :(
>
>
> --
> 叶双明
>

--
叶双明

[叶双明]

Hi Scott,

Yes，modify

def results = dispatcher.runSync("createOrder", serviceCtx)

to

def results = dispatcher.runSync("createOrder", serviceCtx, 60, true)

would make my secas works as expected. But i need to modify so many
code in Event
to resolve similar problem, I think it is a bad smell for the entire system.

And I still worry about i mentioned above 1,2.

Thanks & Regards

2016-07-26 15:56 GMT+08:00 Scott Gray <[hidden email]>:

> You can leave your code mostly the same, but just require a new transaction
> for createOrder, you'll see the option available in the runSync overloaded
> methods.
>
> I've been working with an older version of OFBiz for the last few years so
> I wasn't aware of this change, but I believe it is better than what we had
> before.  The primary purpose of an event in OFBiz is to perform some sort
> of action, and it is very easy for developers to unwittingly directly write
> to the database inside an event.  Obviously this is problematic when the
> updates aren't wrapped in a transaction.  Virtually everything else in
> OFBiz automatically begins a transaction (services, simple methods,
> screens, etc.) and I think it was a good idea for the sake of consistency
> to have the same behavior with events.
>
> The behavioral change between versions is regrettable, but also unavoidable
> if we want to progress.
>
> Regards
> Scott
>
> On 26 July 2016 at 19:02, 叶双明 <[hidden email]> wrote:
>
> > Hi all:
> >
> > After update ofbiz to 13.07.03, our system was Unstable. At last, I found
> > the cause was The transaction created in Event, introduced in revision
> > 1,740,632.
> > And found https://issues.apache.org/jira/browse/OFBIZ-6808.
> > But I doubt whether it is good to do this.
> >
> > In my opinion:
> >
> > 1. It would make more long-running transaction.
> >     For example, there was a event which call three services, the three
> > services has their own transaction before the change, but now there is
> one
> > big transaction for the event and three services, of course the
> transaction
> > would run longer time.
> >
> > 2. It would make a lots of transaction run longer time.
> >     Almost all event would do something else after call service, for
> > example, convert the result from service to JSON format, but the
> conversion
> > not need transaction!
> >
> > 3. It makes it difficult to manage transactions between services and
> > events.
> >     For example, there was a event:
> >
> >     public String createOrder() {
> >
> >         //some business process here... and define serviceCtx
> >
> >         def results = dispatcher.runSync("createOrder", serviceCtx)
> >
> >         //some business process here... and return success or error at
> last
> >
> >     }
> >
> >     after call createOrder service success, i want to fire a jms
> > service(call it jmsIndexOrder) to index the order in Elasticsearch。
> >     I use secas before the change, everything work well.
> >
> >     <eca service=“createOrder” event="return">
> >         <action service="jmsIndexOrder" mode="sync"/>
> >     </eca>
> >
> >
> >     but now i don't know where ant how to call jmsIndexOrder. :(
> >
> >
> > --
> > 叶双明
> >
>

--
叶双明

[Jacques Le Roux]

Hi 叶双明,

One thing we could do is introduce a parameter in the event handler to have or not a transaction. By default we would have one. This seems simple
enough to implement.

Please open a Jira and I'll take care of it, the same way we did for the metric attribute of the event element. This would work also for the
firstvisit, preprocessor, postprocessor, after-login, and before-logout event types.

Thanks

Jacques


Le 26/07/2016 à 09:02, 叶双明 a écrit :

> Hi all:
>
> After update ofbiz to 13.07.03, our system was Unstable. At last, I found
> the cause was The transaction created in Event, introduced in revision
> 1,740,632.
> And found https://issues.apache.org/jira/browse/OFBIZ-6808.
> But I doubt whether it is good to do this.
>
> In my opinion:
>
> 1. It would make more long-running transaction.
>      For example, there was a event which call three services, the three
> services has their own transaction before the change, but now there is one
> big transaction for the event and three services, of course the transaction
> would run longer time.
>
> 2. It would make a lots of transaction run longer time.
>      Almost all event would do something else after call service, for
> example, convert the result from service to JSON format, but the conversion
> not need transaction!
>
> 3. It makes it difficult to manage transactions between services and events.
>      For example, there was a event:
>
>      public String createOrder() {
>
>          //some business process here... and define serviceCtx
>
>          def results = dispatcher.runSync("createOrder", serviceCtx)
>
>          //some business process here... and return success or error at last
>
>      }
>
>      after call createOrder service success, i want to fire a jms
> service(call it jmsIndexOrder) to index the order in Elasticsearch。
>      I use secas before the change, everything work well.
>
>      <eca service=“createOrder” event="return">
>          <action service="jmsIndexOrder" mode="sync"/>
>      </eca>
>
>
>      but now i don't know where ant how to call jmsIndexOrder. :(
>
>