The difference here, is that any row locked via the SELECT .. FOR
UPDATE will not even allows readers access to that record until, so
you will not have processes concurrently trrying to process. This
means that, for each row, any processes acting on it are force to be
seqential each each subseque
On 14 Mar 2007, at 18:02, Michael Dykman wrote:
SELECT * from process WHERE WHERE id = 123 AND status = 'init' FOR
UPDATE;
-- do a bunch of other stuff ...
UPDATE process SET status = 'ready' WHERE id = 123 AND status =
'init';
I get what you're doing here, but I don't see why it's nece
On 13 Mar 2007, at 13:44, JamesDR wrote:
With what you've provided us: You can not prevent this. You are
running
in a transaction which is isolated from any others.
But doesn't that isolation provide atomicity, i.e. the first
transaction to commit will act as if all of its component querie
Marcus Bointon wrote:
> Hi,
>
> (repeat posting)
>
> I have a simple PHP function that initialises a process definition. To
> prevent it happening more than once, I'm wrapping it in a transaction,
> however, it doesn't seem to be working and I get multiple
> initialisations. In pseudocode:
>
> B
Hi,
(repeat posting)
I have a simple PHP function that initialises a process definition.
To prevent it happening more than once, I'm wrapping it in a
transaction, however, it doesn't seem to be working and I get
multiple initialisations. In pseudocode:
BEGIN;
UPDATE process SET status =
Hi,
I have a simple PHP function that initialises a process definition.
To prevent it happening more than once, I'm wrapping it in a
transaction, however, it doesn't seem to be working and I get
multiple initialisations. In pseudocode:
BEGIN;
UPDATE process SET status = 'ready' WHERE id =
Hi,
I have a simple PHP function that initialises a process definition.
To prevent it happening more than once, I'm wrapping it in a
transaction, however, it doesn't seem to be working and I get
multiple initialisations. In pseudocode:
BEGIN;
UPDATE process SET status = 'ready' WHERE id =
