in reply to Re: Concurrency control in web applications in thread Concurrency control in web applications
In a web application, you can't use transactions across multiple HTTP requests. You have no way of knowing if the user is even still there. And every edit involves at least two requests: one to get the form with the data being edited, and the second to submit the changes. You can only use a transaction later when processing the submitted form, at which point you may be clobbering someone else's edit.
Re: Re: Re: Concurrency control in web applications
by IlyaM (Parson) on Oct 27, 2003 at 12:54 UTC
|
I once interviewed one developer and he told me about the project he was worked in the past where they handled exactly this problem. They used separate backend daemon process which would maintain persistent database connections each of them tied to individual user session. This way it was no brainer to use transactions and locks across multiple HTTP requests.
| [reply] |
|
As a matter of fact, merlyn has a column on that. However, it's not scalable for large systems because it requires so many resources to be kept alive on the server side for every client. It also makes failover between servers impossible.
| [reply] |
|