Hello Scott, thanks for your return, in line ...
On 9/17/19 10:45 AM, Scott Gray wrote:
Has anyone ever had a good experience with transaction timeouts? I feel like they achieve nothing useful in that: 1. They don't interrupt any work that is taking too long (they just prevent it from being committed) 2. By the time the exception is thrown, all the work is already done and the result is that it just gets thrown away in exchange for an error Surely there's a positive side to them, and I've just never seen it?
Completely agree, it's also my life :) , transaction timeout it's just a pain to be sure that you waste your time.
Currently the advantage that I saw, it's detect an unexpected too long service and help to spend enough time to optimize it or thinking about an other solution.
But Nicolas, in your case I think the solution lies elsewhere. I don't think it's ever ok for a screen to take over a minute to load and tie up the http connection all that time. Slow pages happen to all of us, but IMO the solution always lies in making the screen faster, limiting the amount of data that can be processed in a single request or by making the request asynchronous.
Sure, I'll join you there. It's generally my first step, currently I most concentrate on the second step, decrease error raise where there is no benefit.
Do you have an objection if I implement the properties explained below with the current default value (60s)? Like this no change for general case, and for server with high load, free will for administrator site to adjust it.
Cheers, Nicolas
Regards Scott On Wed, 11 Sep 2019 at 06:57, Nicolas Malin <nicolas.ma...@nereide.fr> wrote:Hi all, Since I increase the sensibility of error message [1], we have on different screen that take some time to rendering an error throw due to transaction timeout. By default each screen is rendering with the default timeout (60s) that isn't enough when you have big data compilation or some external service latency. Of course it's possible to analyze each case with purpose to increase the screen velocity or set a transaction-timeout on screen definition, but as first easy step what do you think if we add a default transaction timeout for screen to 10 minutes with possibility to override by properties ? Example: ***************************** framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget { // wrap the whole screen rendering in a transaction, should improve performance in querying and such Map<String, String> parameters = UtilGenerics.cast(context.get("parameters")); boolean beganTransaction = false; - int transactionTimeout = -1; + int transactionTimeout = UtilProperties.getPropertyAsInteger("widget", "widget.transaction.timeout.default", 600); if (parameters != null) { String transactionTimeoutPar = parameters.get("TRANSACTION_TIMEOUT"); if (transactionTimeoutPar != null) { @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget { // If transaction timeout is present, use it to start the transaction // If transaction timeout is set to zero, no transaction is started if (useTransaction) { - if (transactionTimeout < 0) { - beganTransaction = TransactionUtil.begin(); - } - if (transactionTimeout > 0) { - beganTransaction = TransactionUtil.begin(transactionTimeout); - } + beganTransaction = TransactionUtil.begin(transactionTimeout); } // render the screen, starting with the top-level section ******************************* Any remarks ? In parallel i will investigate why the error message catch is so sensible. Nicolas [1] http://svn.apache.org/viewvc?view=revision&revision=1856175 -- logoNrd <https://nereide.fr/> Nicolas Malin The apache way <http://theapacheway.com/> : *Charity* Apache’s mission is providing software for the public good. informat...@nereide.fr 8 rue des Déportés 37000 TOURS, 02 47 50 30 54 Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
