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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
