Re: Concurrency control in web applications

Why do you consider connection-based transactions to be unfeasable for n-tier applications?

I've used them for n-tier applications (not Perl-based ones), but this was before I found out that they might be unfeasable. ;)

Is a real issue with Perl or the DBI modules? Or am I wayyyy out of sync, here?

Comment on Re: Concurrency control in web applications

Replies are listed 'Best First'.
Re: Re: Concurrency control in web applications by perrin (Chancellor) on Oct 24, 2003 at 20:30 UTC
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.	[reply]
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. -- Ilya Martynov, ilya@iponweb.net CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org	[reply]
Re: Re: Re: Re: Concurrency control in web applications by perrin (Chancellor) on Oct 27, 2003 at 13:45 UTC
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]


Perl-Sensitive Sunglasses
	PerlMonks