[EMAIL PROTECTED] wrote:
Well, all this doesn't work (the connection is the always the same in
all methods and functions).
I do not understand this statement.
There are some other things you could mention that might help:
Why do you need these table level locks - what are you trying to achieve
that requires them instead of row level locking?
Have you considered using SELECT ... FOR UPDATE / SELECT ... FOR SHARE
(if appropriate) ?
Can you avoid the explicit locking by using a SERIALIZABLE transaction
instead?
What about the locking is not working correctly?
What is currently happening? What do you expect to happen instead?
What happens if you start up two psql sessions and write the same code
in them by hand? Does the locking interaction work correctly then?
Have you read this documentation:
http://www.postgresql.org/docs/8.3/static/explicit-locking.html
?
Are you using only one connection to the server or more than one? If
more than one, how are you ensuring the right thread uses the right
connection?
Have I to L ock the table, perform some operation on this table, and
unlock the table all in the same function scope?
Locks are released at transaction COMMIT / ROLLBACK, and that's (as far
as I know) the only way to release a lock. You should acquire the lock,
do your work, and commit the transaction, eg:
BEGIN;
LOCK TABLE sometable IN ACCESS EXCLUSIVE MODE;
-- Do your work
COMMIT;
I don't know what function scope could possibly have to do with this or
with your threading. What matters is the SQL you're sending to the
server. Have you tried logging the SQL statements you're sending to the
server and making sure they work as expected in psql?
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
