From: anton.txt@gmail.com   
      
   Thank  you  for the replies, Erland and rja.  I have   
   found what I think is an ambiguity in the documenta-   
   tion:   
      
     Locks  placed  on  a  resource are associated with   
     either the current transaction or the current ses-   
     sion.   
      
   where  the notion of "current transaction" is rather   
   unintuitive, for it refers not to the scope  of  the   
   immediate  enfolding  BEGIN  TRAN  block, but to the   
   outermost one.  The following code:   
      
   DECLARE @lockRes INT   
      
   BEGIN TRAN -- outer transaction   
      BEGIN TRAN -- inner transaction   
         PRINT 'Acquiring lock in the inner transaction...'   
         EXEC @lockRes = sp_getapplock 'test', 'Exclusive'   
         IF @lockRes < 0 PRINT 'Failure.' ELSE PRINT 'Success.'   
      COMMIT TRAN   
      PRINT 'Releasing the lock in the outer transaction...'   
      EXEC @lockRes = sp_releaseapplock 'test'   
      IF @lockRes < 0 PRINT 'Failure.' ELSE PRINT 'Success.'   
   COMMIT TRAN   
      
   outputs:   
      
   Acquiring lock in the inner transaction...   
   Success.   
   Releasing the lock in the outer transaction...   
   Success.   
      
   which means that the life of a transaction lock ter-   
   minates with that of the *outermost* transaction.   
      
   --   
   ()  ascii ribbon campaign -- against html e-mail   
   /\  http://preview.tinyurl.com/qcy6mjc [archived]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)