Re: [SQLObject] collision detection strategy

[Bud P. B. <bu...@si...>]

> Can you explain what you mean by "take out a lock"?

I suppose the correct term would be acquire a lock.
This idea comes from the diagram for optimistic locking at
http://www.agiledata.org/essays/concurrencyControl.html#OptimisticLocking.

I also looked into the Postgres documentation and it states:

<quote
src=http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=explicit-locking.html#LOCKING-ROWS>

 In addition to table-level locks, there are row-level locks. A
 row-level lock on a specific row is automatically acquired when the
 row is updated (or deleted or marked for update). The lock is held
 until the transaction commits or rolls back. Row-level locks don't
 affect data querying; they block writers to the same row only. To
 acquire a row-level lock on a row without actually modifying the row,
 select the row with SELECT FOR UPDATE . Note that once a particular
 row-level lock is acquired, the transaction may update the row
 multiple times without fear of conflicts.

</quote>

So I guess that at least in Postgres, row locks are acquired
automatically...

I see little probability for problems when updating a single object
(table row) since it is a single (atomic??) SQL command.  Trouble is
more likely if in a transaction, several related (as in 1:many or
many:many relationships) objects need to be updated in a transaction.
It seems Postgres takes care of this too since it locks for the
duration of the whole transaction...  Hmmmm...  but it locks the
row...  So if two transactions try to modify a set of objects at the
same time, both may lock rows but deadlock each other???

Hmm...  I'm not good at this kind of stuff...seems difficult...

--b