Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Timeout caused by PHDBase
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
West Wind Web Connection
Divers
Thread ID:
00970226
Message ID:
00970358
Vues:
16
Michel,

For processes that could possibly timeout it's best to move those off to an asynchronous process. WWWC comes with a class for doing just that--lookup the wwAsyncWebRequest class in the help file. If you have the WebRAD book, there's also a clear example of how an async request works.

>I am facing a situation with the combination of WWC and PHDBase that I am trying to resolve. Before executing a PHDBase search, in here for example when someone does a search, I am applying a SetTimeout() at the Msxml2.ServerXMLHTTP object level, so assuming a search would be too long, the timeout would occur and a message would be returned to the user. So far, so good, when this is rarely happening, it is working fine. The WWC transaction is completed with success.
>
>But, when someone execute a search on all years, I have to run the process into a loop. So, the loop will be executed 8 times. Assuming all results are returned within the timeout, all would be ok at the search level. But, the problem is that because this is into a loop, the total amount of time of each search for those years could exceed the WWC timeout. So, in this case, it generates a WWC failure with the standard message being returned to the user and the WWC VFP server instance is being restarted.
>
>For me, I can't afford to have that to be done. I need to make sure that, if a WWC VFP server instance is started, it would be because I would have decided so.
>
>So, I've been thinking about this PHDBase structure again tonight. Basically, the search is not done on the production table. I wouldn't recommend that to anyone. There are obvious reasons for that. So, I have a robot which is synchronizing additional yearly tables based on that main table which are only used for the search. So, I have a table of messages per year which sums them all.
>
>I thought that by splitting those tables that I would gain on speed result. But, is that really the case? While I am indexing PHDBase on a full copy of the main table, which takes about an hour to do all that because of the million messages, in order for me to compare speed result, I thought about posting a message in here to collect feedback.
>
>PHDBase works with VFP indexes. So, if I have 150,000 messages in average per table for the search compare to having one table with one million messages, if we are using VFP indexes, isn't the speed result be about the same?
>
>Anyone did that comparism before? The only comparism I did so far for that search structure was to use SQL Server. So far, my results gave that SQL Server search engine was as fast as PHDBase. I didn't switch to SQL Server for that search engine because I have something which is working ok for now.
>
>But, I would like to resolve that issue when the search is timing out because of big search process. If I would have everything into one table, which is what I would know in about two hours, if I would hit a big search process, the timeout would occur and the WWC transaction would be returned ok to the user with the message telling that the search criteria could be refined because the word entered is too generic thus too may results. And, again, that would work because I would eliminate the loop process of accumulating the number of seconds for each year causing, in rare cases, a timeout at WWC level.
>
>For those who are wondering why I don't increase the timeout at WWC level, well, I just don't want to. I figure that 50 seconds should be ok to return a transaction. Other than that, we better advise the user about what is going on. Because, when that would be the situation, the user will probably cancel the transaction before it would finish assuming that I would increase the timeout to 120 seconds, for example.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform