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.
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
