On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:
> On 9/22/06, AgentM <agentm@themactionfaction.com> wrote:
>> I would be more worried about accidental collisions between
>> applications. The lock ranges will now need to be in their respective
>
> i dont think this argument has merit because the lock is scoped to the
> current database. this would only be a problem if two applications
> used the same database...not likely.
Since we have schemas, I have several applications running in one
database- sometimes several versions of the same application. This
makes it easier to shuffle data around.
>> application's configuration file in case of collision with another
>> app once developers really start using locks for IPC. Ideally, the
>> user-level lock functions would take strings instead of integers and
>> hash them appropriately, no? Otherwise, someone will end up
>> maintaining a registry of lock numbers in use. LISTEN doesn't use
>> integers.
>
> application can translate the locks to strings via a very simple
> translation table. there is no downside to this besides a index
> lookup on a small table, which is more or less what the listen/notify
> does internally.
>
> advisory locks work off of the internal lock system which is an
> integer only system. the whole point is to get at these locks while
> bypassing the transaction system. you are suggesting something which
> does not fit into the current lock system.
I didn't suggest using lookup tables; I suggested that the lock
functions should perform the string hashing itself- the applications
will write wrappers for this anyway to prevent collisions or they
will have to provide some configuration element to change the lock
range in case of collision- which will be extraordinarily difficult
to debug in the first place.
-M
