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 <[email protected]>:
> 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, 叶双明 <[email protected]> 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. :(
> >
> >
> > --
> > 叶双明
> >
>
--
叶双明
