Comments on: Explicit Table Locking with PostgreSQL and Django http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/ Blog | Django Web Development | Raleigh Durham Chapel Hill | Caktus Consulting Group Thu, 09 Sep 2010 15:21:50 +0000 http://wordpress.org/?v=2.6.3 By: Angelo Dell'Aera http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-464 Angelo Dell'Aera Mon, 16 Nov 2009 11:11:57 +0000 http://www.caktusgroup.com/blog/?p=218#comment-464 Nice code. I was thinking about making it really generic. Think about this idea. You import settings.py thus being able to read DATABASE_ENGINE. Then you define LOCK_MODES this way LOCK_MODES = {'postgresql_psycopg2' : POSTGRESQL_LOCK_MODES, 'mysql' : MYSQL_LOCK_MODES, ...} (with POSTGRESQL_LOCK_MODES being the same tuple as your LOCK_MODES) In wrapper then def wrapper(*args, **kwargs): if DATABASE_ENGINE not in LOCK_MODES.keys(): raise ... if lock not in LOCK_MODES[DATABASE_ENGINE]: raise ... if DATABASE_ENGINE == "postgresql_psycopg2": postgresql_psycopg2_lock_table(table, lock) ... return view_func(*args, **kwargs) Nice code. I was thinking about making it really generic. Think about this idea. You import settings.py thus being able to read DATABASE_ENGINE. Then you define LOCK_MODES this way

LOCK_MODES = {’postgresql_psycopg2′ : POSTGRESQL_LOCK_MODES,
‘mysql’ : MYSQL_LOCK_MODES,
…}

(with POSTGRESQL_LOCK_MODES being the same tuple as your LOCK_MODES)

In wrapper then

def wrapper(*args, **kwargs):
if DATABASE_ENGINE not in LOCK_MODES.keys():
raise …
if lock not in LOCK_MODES[DATABASE_ENGINE]:
raise …
if DATABASE_ENGINE == “postgresql_psycopg2″:
postgresql_psycopg2_lock_table(table, lock)
…
return view_func(*args, **kwargs)

]]> By: tobias http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-403 tobias Tue, 29 Sep 2009 22:54:40 +0000 http://www.caktusgroup.com/blog/?p=218#comment-403 The PostgreSQL docs say "locks are always released at transaction end", which I assume includes ROLLBACKs and connection closures. Try creating a test case for this one and let us know what you find! The PostgreSQL docs say “locks are always released at transaction end”, which I assume includes ROLLBACKs and connection closures. Try creating a test case for this one and let us know what you find!

]]> By: Joe Joe http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-397 Joe Joe Tue, 29 Sep 2009 00:38:57 +0000 http://www.caktusgroup.com/blog/?p=218#comment-397 Shouldn't you add a call to transaction.set_dirty() after the cursor.execute() call? What if the transaction exists entirely of SELECTs(which won't internally call set_dirty)? Will the lock still be properly released? http://docs.djangoproject.com/en/dev/topics/db/sql/#id1 Shouldn’t you add a call to transaction.set_dirty() after the cursor.execute() call? What if the transaction exists entirely of SELECTs(which won’t internally call set_dirty)? Will the lock still be properly released?

http://docs.djangoproject.com/en/dev/topics/db/sql/#id1

]]> By: Graham Fawcett http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-139 Graham Fawcett Fri, 29 May 2009 17:57:56 +0000 http://www.caktusgroup.com/blog/?p=218#comment-139 Excellent recipe! Thank you. One suggestion: consider changing the signature to require_lock(lock, *models) and execute the LOCK TABLE commands once for each of the models given. This would still work for a single-table lock, but would also make it easy to specify multiple tables in a trickier situation. (It would also help to enforce locking-order by documenting it in one place, which might help to avoid deadlocks.) Excellent recipe! Thank you.

One suggestion: consider changing the signature to require_lock(lock, *models) and execute the LOCK TABLE commands once for each of the models given. This would still work for a single-table lock, but would also make it easy to specify multiple tables in a trickier situation. (It would also help to enforce locking-order by documenting it in one place, which might help to avoid deadlocks.)

]]> By: Chirayu Patel http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-131 Chirayu Patel Thu, 28 May 2009 06:52:10 +0000 http://www.caktusgroup.com/blog/?p=218#comment-131 A very useful function. In a similar piece of code, I have also added support for timeout (implemented using time.sleep(random.randint (1, timeout)) and NOWAIT). It helps in identifying lockup problems both in testing and production. A very useful function. In a similar piece of code, I have also added support for timeout (implemented using time.sleep(random.randint (1, timeout)) and NOWAIT). It helps in identifying lockup problems both in testing and production.

]]> By: Caktus Blog » Blog Archive » Testing Django Views for Concurrency Issues http://www.caktusgroup.com/blog/2009/05/26/explicit-table-locking-with-postgresql-and-django/#comment-117 Caktus Blog » Blog Archive » Testing Django Views for Concurrency Issues Tue, 26 May 2009 20:59:42 +0000 http://www.caktusgroup.com/blog/?p=218#comment-117 [...] Blog « Explicit Table Locking with PostgreSQL and Django [...] [...] Blog « Explicit Table Locking with PostgreSQL and Django [...]

]]>