Re: Foreign Keys Question
| From: | Robert Cummings | 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