Re: User Level Lock question

----- Original Message -----
From: "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Saturday, March 16, 2002 6:54 AM
Subject: Re: [HACKERS] User Level Lock question

> I know it does not sound like something that would need to be done, but
here
> is why I am looking at doing this...
>
> I am trying to replace a low level ISAM database with PostgreSQL. The low
> level ISAM db allows locking a record during a read to allow Exclusive
> access to the record for that process. If someone tries to do a READ
> operation on that record, it is skipped. I have to duplicate this
> functionality. The application also allows locking multiple records and
then
> unlocking individual records or unlocking all of them at once. This cannot
> be done easily with PostgreSQL unless I add a "status" field to the
records
> and manage them. This can be done, but User Level Locks seem like a much
> better solution as they provide faster locking, no writes to the database,
> when the backend quits all locks are released automatically, and I could
> lock multiple records and then clear them as needed. They also exist
outside
> of transactions!
>
> So my idea was to use User Level Locks on records and then include a test
on
> the lock status in my SELECT statements to filter out any records that
have
> a User Level Lock on it. I don't need to set it during the query, just
test
> if there is a lock to remove them from the query. When I need to do a true
> lock during the SELECT, I can do it with the supplied routines.
>
In INFORMIX you have a similar option except that you have the choice to
decide whether the other client blocks or continue, but in any case it
returns an error status. You even can set a delay while you accept to be
bloked and the lock can be set on database, table or record level. We use
table locking to speed up some time consuming processings.
I guess it would be better to have at least an error code returned. The
application can then choose to ignore the error code.

> Does this make any more sense now or have I made it that much more
> confusing?
>
> Lance
>
> ----- Original Message -----
> From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com>
> Cc: <pgsql-hackers(at)postgresql(dot)org>
> Sent: Friday, March 15, 2002 9:11 AM
> Subject: Re: [HACKERS] User Level Lock question
>
>
> > "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com> writes:
> > > Is there an easy way to test the lock on a user level lock without
> actually
> > > issuing the lock?
> >
> > Why would you ever want to do such a thing? If you "test" the lock but
> > don't actually acquire it, someone else might acquire the lock half a
> > microsecond after you look at it --- and then what does your test result
> > mean? It's certainly unsafe to take any action based on assuming that
> > the lock is free.
> >
> > I suspect what you really want is a conditional acquire, which you can
> > get (in recent versions) using the dontWait parameter to LockAcquire.
> >
> > regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>