OFBiz › OFBiz - User

Indirect transaction timeout

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Marc Morin

Indirect transaction timeout

We have a condition where ordering a specific product (electronic product) that can take a long time to perform during the finalize stage. This has to do with the fact that it is a digital subscription, and there is a service attached to the product, and this service creates a new tenant (create database in our case).

This process can take about 50 seconds. Now, on the service definition for this service call, we define a transaction timeout of 120 seconds, yet this doesn't take affect.

It appears that the tranaction timeout field in the service definition only applies to the first service call that initiates the beginning of the transaction. This is very unstable and difficult to manage.

Any idea on how difficult it would be to change the behaviour such that the current transaction timeout is set to the maximum of the current invoked service timeout in the model, vs the timeout in the current active transaction?

Noticed that there wasn't a method call on the transaction interface, so would likely need to be non-standard.

Marc Morin
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 201
[hidden email]

Harmeet Bedi

Re: Indirect transaction timeout

There is require-new-transaction="true". default is false, so reuses settings. Maybe 'true' would do the trick.
If you don't need transaction for external db create, an option could be use-transaction="false"

Harmeet
----- Original Message -----
From: "Marc Morin" <[hidden email]>
To: [hidden email]
Sent: Sunday, July 26, 2009 10:13:06 AM GMT -05:00 US/Canada Eastern
Subject: Indirect transaction timeout

We have a condition where ordering a specific product (electronic product) that can take a long time to perform during the finalize stage. This has to do with the fact that it is a digital subscription, and there is a service attached to the product, and this service creates a new tenant (create database in our case).

This process can take about 50 seconds. Now, on the service definition for this service call, we define a transaction timeout of 120 seconds, yet this doesn't take affect.

It appears that the tranaction timeout field in the service definition only applies to the first service call that initiates the beginning of the transaction. This is very unstable and difficult to manage.

Any idea on how difficult it would be to change the behaviour such that the current transaction timeout is set to the maximum of the current invoked service timeout in the model, vs the timeout in the current active transaction?

Noticed that there wasn't a method call on the transaction interface, so would likely need to be non-standard.

Marc Morin
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 201
[hidden email]

David E. Jones-2

Re: Indirect transaction timeout

In SVN rev 797962 I added some documentation to those attributes about
what they mean and when they are used, and hopefully that will help
with this question.

The way it currently works, and I think this is what you are referring
to Marc, is: when a service has use-transaction=true it will see if
there is a transaction in place and if not it will begin one and it
will use the transaction-timeout value for that service (or the
default); when that service calls another service there is already a
transaction in place and it has already begun; with JTA you cannot
change the transaction timeout after it has already begun, so if the
sub-service wants a higher timeout all it can do is use require-new-
transaction=true but that has the downside of making the operations in
the sub-service independent of the operations in the calling service,
which may not be what you want.

Right now to solve this the developer has to do it manually. In other
words, if you set a higher transaction-timeout value for a service
then you should also look to see which services call that service (the
Artifact Info tool can help with this, and is quite reliable if the
services are written in simple-methods, and gets most stuff for Java
services (but not all with the current simplistic implementation)),
and then set the transaction-timeout higher on those services (and on
the calling services it should maybe be even higher to allow time for
whatever that service and other services it calls to run).

If I understand what you are suggesting Marc it is to do some analysis
at runtime, perhaps using the Artifact Info stuff, and evaluate the
entire tree of services that this service might call (no guarantee
they will be called, just all that it might call) and see if any have
a higher transaction-timeout value and if so then use a higher
transaction-timeout for this service. Is that a correct interpretation
of your suggestion?

-David

On Jul 26, 2009, at 9:11 AM, Harmeet Bedi wrote:

> There is require-new-transaction="true". default is false, so reuses
> settings. Maybe 'true' would do the trick.
> If you don't need transaction for external db create, an option
> could be use-transaction="false"
>
> Harmeet
> ----- Original Message -----
> From: "Marc Morin" <[hidden email]>
> To: [hidden email]
> Sent: Sunday, July 26, 2009 10:13:06 AM GMT -05:00 US/Canada Eastern
> Subject: Indirect transaction timeout
>
> We have a condition where ordering a specific product (electronic
> product) that can take a long time to perform during the finalize
> stage. This has to do with the fact that it is a digital
> subscription, and there is a service attached to the product, and
> this service creates a new tenant (create database in our case).
>
> This process can take about 50 seconds. Now, on the service
> definition for this service call, we define a transaction timeout of
> 120 seconds, yet this doesn't take affect.
>
> It appears that the tranaction timeout field in the service
> definition only applies to the first service call that initiates the
> beginning of the transaction. This is very unstable and difficult
> to manage.
>
> Any idea on how difficult it would be to change the behaviour such
> that the current transaction timeout is set to the maximum of the
> current invoked service timeout in the model, vs the timeout in the
> current active transaction?
>
> Noticed that there wasn't a method call on the transaction
> interface, so would likely need to be non-standard.
>
> Marc Morin
> Emforium Group Inc.
> ALL-IN Software™
> 519-772-6824 ext 201
> [hidden email]
>
>

Marc Morin

Re: Indirect transaction timeout

David,

As you pointed out, there is a LOT of manual investigation in order to handle this case. I understand that this is how it needs to be done now, but this tends to make the implementations unstable (either because forgot or missed a long timeout case on a specific entry point, or by artificially increasing the default time to a too-large value).

The static analysis case is difficult when confronted with optional service invocations...

I don't want to create a sub-transaction as I need the "longer process" to be part of the outer transaction and maintain the commit/rollback semantics.

----- Original Message -----
From: "David E Jones" <[hidden email]>
To: [hidden email]
Sent: Sunday, July 26, 2009 1:55:29 PM GMT -05:00 US/Canada Eastern
Subject: Re: Indirect transaction timeout

In SVN rev 797962 I added some documentation to those attributes about
what they mean and when they are used, and hopefully that will help
with this question.

The way it currently works, and I think this is what you are referring
to Marc, is: when a service has use-transaction=true it will see if
there is a transaction in place and if not it will begin one and it
will use the transaction-timeout value for that service (or the
default); when that service calls another service there is already a
transaction in place and it has already begun; with JTA you cannot
change the transaction timeout after it has already begun, so if the
sub-service wants a higher timeout all it can do is use require-new-
transaction=true but that has the downside of making the operations in
the sub-service independent of the operations in the calling service,
which may not be what you want.

Right now to solve this the developer has to do it manually. In other
words, if you set a higher transaction-timeout value for a service
then you should also look to see which services call that service (the
Artifact Info tool can help with this, and is quite reliable if the
services are written in simple-methods, and gets most stuff for Java
services (but not all with the current simplistic implementation)),
and then set the transaction-timeout higher on those services (and on
the calling services it should maybe be even higher to allow time for
whatever that service and other services it calls to run).

If I understand what you are suggesting Marc it is to do some analysis
at runtime, perhaps using the Artifact Info stuff, and evaluate the
entire tree of services that this service might call (no guarantee
they will be called, just all that it might call) and see if any have
a higher transaction-timeout value and if so then use a higher
transaction-timeout for this service. Is that a correct interpretation
of your suggestion?

-David

On Jul 26, 2009, at 9:11 AM, Harmeet Bedi wrote: