Oh you are definitely right. I made up the example as I was writing the
post, this is not a real case in my application.. Besides, I use ACL for
privileges :)
But such cases do happen (inserting or updating based on a SELECT result)
and it can't always be solved with 1 save as it might depend on results from
multiple queries from multiple tables (Hence the need for locking).
GET_LOCK almost always solves it. (I had never used it before. I researched
it when you mentioned it). Correct me if I'm wrong, but I noticed that the
drawback of GET_LOCK is that you need to know which scripts might have
common results in order to make them require the same lock.
example:
script 1: SELECT * FROM employees WHERE position='manager';
if (condition)
UPDATE employees SET ...
script 2: SELECT * FROM employees WHERE salary>= 2000;
if(condition)
UPDATE employees SET ...
Here one would probably make them both require the same lock ( like
GET_LOCK('employee_update')) to ensure they don't change each others'
results if run at the same time, and therefore make them wait for each other
every time they run concurrently. SELECT FOR UPDATE on the other hand would
only make them wait for each other if, in that particular instance, they had
common records.
On Mon, Aug 15, 2011 at 9:29 PM, 0x20h <k...@informatik.uni-marburg.de>wrote:
> Am 14.08.2011 12:46, schrieb Teddy Zeenny:
> > That is an interesting idea. (Although I don't think it would give me
> > the exact SELECT .. FOR UPDATE functionality, but I guess it's as
> > close as I can get).
> It would only allow 1 Process to access the if clause and it would
> return *immediately* on *all* clients while FOR UPDATE blocks all other
> processes that try to
> SELECT the particular id (could be many, could be long). Of course,
> while SELECT...FOR UPDATE explicitly locks the row, the GET_LOCK
> functionality is an advisory technique where all participating sides
> have to obtain the lock (e.g. the code part that takes away the is_admin).
>
> Anyway, I think your concerns are a bit overkill and probably a flaw in
> your application design (e.g. why would you have an is_admin flag and
> then later set privileges => 'all' in another query)
> Would it not solve the problem if you had a save() that does both at once?
>
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org
> Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
>
>
> To unsubscribe from this group, send email to
> cake-php+unsubscr...@googlegroups.com For more options, visit this group
> at http://groups.google.com/group/cake-php
>
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/cake-php
