2 Replies Latest reply: Feb 20, 2012 1:19 PM by user11188564 RSS

    BDB 5.2 Error message reported on std out

    186011
      While testing with 5.2 (we are planning ro upgrade to 5.2) we see the following message reported on
      the Screen -

      EnvLOC /tmp/testDB/MYDB
      /tmp/testDB/MYDB: DB_LOCK->lock_put: Lock is no longer valid

      My application continues to run - i.e. does not get any errors.

      My question - is this something I should be worried about. The message "Lock is no longer valid" seems to indicate there may be some consistency related issue.
        • 1. Re: BDB 5.2 Error message reported on std out
          "Andrei Costache, Oracle-Oracle"
          Hi rittick,

          I need more info on this issue:
          1. What is the exact BDB version you are using (e.g. 5.2.19, 5.2.36)? On what platforms/OS?
          2. Is this issue reproducible at will? Can you provide a small stand-alone test case program?
          3. What is the access method of the database on which you are performing the operation (e.g. Btree, Recno)? What isolation degree flag are you using (e.g. DB_READ_COMMITTED, DB_READ_UNCOMMITTED)?
          4. Are you acquiring and releasing locks explicitly by using the lock_get(), lock_put() or lock_vec() methods?
          5. If you can reproduce it, put a breakpoint on the following line in db-5.2.PP/src/lock/lock.c:
                    __db_errx(env, __db_lock_invalid, "DB_LOCK->lock_put");
          or simply put a breakpoint on the __db_errx function. Get the stack trace when the breakpoint is hit and dump the content of lock and lockp (i.e. in gdb do a print lock, print lockp).

          Regards,
          Andrei
          • 2. Re: BDB 5.2 Error message reported on std out
            user11188564
            1. What is the exact BDB version you are using (e.g. 5.2.19, 5.2.36)? On what platforms/OS?

            We are using 5.2.36 on HPUX 11.3.1

            2. Is this issue reproducible at will? Can you provide a small stand-alone test case program?

            No - we have seen the message several times. We have a process that is multithreaded. The threads have their own handle. The threads do all inds of DB operations - DELETES, INSERTS, UPDATES and SELECTS.

            3. What is the access method of the database on which you are performing the operation (e.g. Btree, Recno)? What isolation degree flag are you using (e.g. DB_READ_COMMITTED, DB_READ_UNCOMMITTED)?

            BTREE with the default isolatation mechanism.

            4. Are you acquiring and releasing locks explicitly by using the lock_get(), lock_put() or lock_vec() methods?\

            No

            5. If you can reproduce it, put a breakpoint on the following line in db-5.2.PP/src/lock/lock.c:

            We will try our best.


            Thanks you for for your help.