Re: Foreign Keys Question

From: Date: Thu, 11 Dec 2008 21:25:25 +0000
Subject: Re: Foreign Keys Question
References: 1 2 3 4 5 6 7 8  Groups: php.general 
Request: Send a blank email to php-general+get-284508@lists.php.net to get a copy of this message
On Thu, 2008-12-11 at 16:24 -0500, Robert Cummings wrote: > On Thu, 2008-12-11 at 16:17 -0500, tedd wrote: > > At 3:14 PM -0500 12/11/08, Andrew Ballard wrote: > > > > > >That's the way to go. Just keep in mind that you will have to consider > > >ways of preventing overloading your courses due to concurrency, > > >whether you use table locks or devise your own mechanism. I don't know > > >if you are allowing students to self-enroll or not. You just don't > > >want two users to both see that a course has one opening left and both > > >try to take that spot at the same time. > > > > > >Andrew > > > > It's very low volume at the moment, so I don't think there will be an > > immediate problem. > > > > However, I will investigate locking the tables for entry. But I don't > > think using transactions will be necessary. > > A site doesn't need to be high volume to get a concurrency issue. The > timing just needs to be right. So there's less probability in a low > traffic site, but all the same, the problem produced as a result is the > same. In a low volume site using a lock on the table is a simple method > to prevent the problem since you can expect it will have minimal impact > on the site in general (due to low volume). You only need the lock when > you go to add the row... > > lock table > check enrolment count > no room > unlock table > generate error > have room > insert row > unlock table > > Ba da boom. I should have read your message better... you were talking about skipping transactions and not locking :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP

« previous php.general (#284508) next »