Thread Rating:
  • 1 Vote(s) - 2 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Session is already locked - Causes instability
#11
(07-13-2020, 10:22 AM)Alexandre Machado Wrote: That's not the only recommendation. I also suggested that you disable the UI while you post a request. IntraWeb controls have a LockOnAsyncEvents property. Use it. That's the only way to prevent a impatient user to post hundreds of requests in just a few seconds.
Thanks Alexander, the LockOnAsync event is on for button click, setting the timeout to 0 didn’t work however 15 mins allowed me to log a bottleneck in the signature routine (a lazy crop white space routine), though I thought each would be threaded I believe we were receiving a massive image for the signature, I will try and put together a test to simulate and report back results.
Reply
#12
Your response is confusing. IntraWeb *is* threaded. Each session runs in its own thread. One session won't wait for other sessions (unless, of course, you are using all computer processors indefinitely to handle other stuff)

But IntraWeb won't fix problems in your code. If something is being shared and spending an enormous time to run, there is nothing IW can do.
Reply
#13
You may wish to look in our demos for the thread example which spawns an additional thread for long running tasks and uses a progress bar to update the user. Maybe its useful in your scenario.
Reply
#14
Just an update and thank you, extending the LockSessionTimeout and fixing the slow response has stopped the error Smile
Reply
#15
Great!

Thanks for the feedback :-)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)