Explanation of long running form submit
When working with various types of form submissions, you’re likely to encounter an experience where a web or desktop application seems to hang or just sit idle . In most cases, the application isn’t hung or idle, it’s just blocked the user interface and its users from performing any other operations or processes (a thread) until the current operation is finished, which leads users to be misled on what is occurring with the application.
In computer programming, a thread is considered an execution of the smallest sequence of programmed instructions that is managed independently by an operating system. Threads are similar to a process; however, processes are generally independent, whereas a thread exists as a child of a process.
In computer applications, when a user interface component requests operations from a server, whether it’s a database or other types of processes, such as sending an email, these occur within threads. Sometimes, depending on the operations, these threads can take time to process and return an appropriate result to the visual component. As a result, these threads are locked so that other competing resource, such as a success message or a grid control being filled on the user interface doesn’t interrupt the previous thread.
While the locked thread is working, the user interface and user are left wondering, why is my action that was performed appear to be idle? The answer lies in the user interface - it doesn’t know natively that an operation is occurring behind the scenes. In essence its dumb to the idea there’s a locked thread running a time-sensitive operation. As a result, we need a way to instruct visually to the user that the application is processing a long running operation and needs time to finish before the next operation - visually indicating to the user the operation is complete - can occur.
What solutions are available?
The solutions available depend on what operations are being performed.
In a case such as Creating a ASP.NET MVC Contact Form, the long running process is sending the mail message via the send method of the Simple Mail Transfer Protocol (SMTP) class. SMTP servers are generally chatty Cathy’s for a variety of reasons including:
- Timeouts on the SMTP server
- Validation of the email for the SMTP server
- Rules in place to prevent sending emails on timed intervals
- Serializing the email in order for it to be sent across the Internet
To remedy the long running process, you have a couple different options including:
- Send the emails to a temporary location on the sending SMTP server. Once delivered, we could write additionally logic to read from the queue and send mail
In this specific case, the latter solution is probably the only option, since most people use shared hosting and most providers wouldn’t allow you to access or write messages to their SMTP servers.
In database operations, the latter solution is still probably the best option, if you need it.
One implementation approach for a web application can be found at:
I've used this before on this site and it worked.
If you’d like additional examples/ideas, a simple Google search query such as long running form submits will deliver additional options if you’re dealing with a desktop application.
If you have questions, contact me.