Mon Dec 19 16:59:36 CET 2005
--- "Vlad Dumitrescu XX (LN/EAB)"
> Please correct me if I'm wrong, but when just
> updating a row there
> shouldn't be a big problem since this "lock" is held
> just briefly. It's
> possible that most clients won't notice it (this is
> true for a single
> CPU, where there's just one execution context
> running at a given time
> anyway, right?).
Your operation will still have to wait until all
preceding table requests are done, regardless of
whether they overlap with yours. If these requests
arrive at a rate such that the table owner message
queue doesn't build up, good. Otherwise, very bad :-)
> Where the problem would be more visible is when
> doing many/bulk updates
> to only one part of a table, while others might need
> to read from
> unrelated parts.
That's one example.
> This brings up a (mad?) vision: if Erlang processes
> had internal threads
> (or in a equivalent view, several processes shared
> state), then one
> could only "lock part of a table" for each one of
> Hmmm, what a can of worms... ;-)
Heh heh, yes indeed :-)
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the erlang-questions