Re: DBMS_LOCK.ALLOCATE_UNIQUE

Tim, I just ran your both examples on my Linux database and I got different
locks in both cases. Here is what happned:

SQL*Plus: Release 9.2.0.3.0 - Production on Wed May 14 18:26:35 2003

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production With the Partitioning option
JServer Release 9.2.0.3.0 - Production

SQL> @/tmp/1
10737418241073741824147
10737418251073741825148

PL/SQL procedure successfully completed.

SQL> @/tmp/2
10737418241073741824147
10737418251073741825148

PL/SQL procedure successfully completed.

SQL> /tmp/1.sql and /tmp/2.sql are attached.

On 2003.05.14 18:01 "Johnston, Tim" wrote:
> Hi Everyone...
>
> I've encountered a strange issue and wanted to know if anyone else
> have
> ever seen something like this... I've had this issue occur on two
> different
> systems... In each case the systems Solaris 9 running 9.2.0.2 and
> then
> upgraded to 9.2.0.3... The issue is when you supply a string to
> DBMS_LOCK.ALLOCATE_UNIQUE you should get a unique lock handle back...
> For
> example...
>
> SQL> Declare
> 2 sLockName1 Varchar2(100) :=
> 'PARTITION_C02_NRAW_000_H0_2003050400_LCK';
> 3 sLockName2 Varchar2(100) := 'PVM_VIEWS_NRAW_000_LCK';
> 4 sLockHandle1 Varchar2(100);
> 5 sLockHandle2 Varchar2(100);
> 6 Begin
> 7 Dbms_Lock.Allocate_Unique( sLockName1, sLockHandle1 );
> 8 dbms_output.put_line(sLockHandle1);
> 9 Dbms_Lock.Allocate_Unique( sLockName2, sLockHandle2 );
> 10 dbms_output.put_line(sLockHandle2);
> 11 End;
> 12 /
> 10737418251073741825148
>
> 10737418261073741826149
>
>
> PL/SQL procedure successfully completed.
>
>
> But, I am encountering a situation where two DIFFERENT lock names are
> producing the EXACT SAME lock handle... i.e.
>
>
> SQL> Declare
> 2 sLockName1 Varchar2(100) :=
> 'PARTITION_C02_NRAW_000_H0_2003050500_LCK';
> 3 sLockName2 Varchar2(100) := 'PVM_VIEWS_NRAW_000_LCK';
> 4 sLockHandle1 Varchar2(100);
> 5 sLockHandle2 Varchar2(100);
> 6 Begin
> 7 Dbms_Lock.Allocate_Unique( sLockName1, sLockHandle1 );
> 8 dbms_output.put_line(sLockHandle1);
> 9 Dbms_Lock.Allocate_Unique( sLockName2, sLockHandle2 );
> 10 dbms_output.put_line(sLockHandle2);
> 11 End;
> 12 /
> 10737418261073741826149
>
> 10737418261073741826149
>
>
> PL/SQL procedure successfully completed.
>
>
> Has anyone seen anything like this before?
>
> Regards,
> Tim Johnston
> Tel: 978-322-4226
> Fax: 978-322-4100
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Johnston, Tim
> INET: TJohnston_at_quallaby.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Mladen Gogala



-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mladen Gogala
  INET: mgogala_at_adelphia.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



text/x-sql attachment: 1.sql



text/x-sql attachment: 2.sql