Forum Stats

  • 3,768,724 Users
  • 2,252,841 Discussions
  • 7,874,696 Comments

Discussions

Got Exception on deleting a database with two secondaryDatabase

531207
531207 Member Posts: 11
edited Sep 4, 2006 11:43AM in Berkeley DB Java Edition
I always got the exception while deleting a database which having two secondary database(@secondaryKey).

I'm using the Persistence API and i'm using a SecondaryKey.delete(keyvaule) method. Notice that the Database have two Secondarydabase.

I'm using the first one(docIdFk) to delete,but got Lock expired exception on deleting the second one(TermPrxData#termInfoFk).

The Exception Info are as follows. I don't know how to avoid this since i thougt this is quite a simple operation.:

(JE 3.0.12) Lock expired. Locker 73_main_AutoTxn: waited for lock on database=persist#EntityStore#org.apache.lucene.store.bdb.TermPrxData#termInfoFk node=134 type=WRITE grant=WAIT_NEW timeoutMillis=500 startTime=1157334151410 endTime=1157334152410
Owners: [<LockInfo locker="-1_main_ThreadLocker" type="READ"/>]
Waiters: []


And because of this the following two deleting operation can't work too:

((JE 3.0.12) Failed while attempting to commit transaction 76, aborted instead. Original exception = (JE 3.0.12) Transaction 76 must be aborted.).

Thanks for help
Richie

New discovery: when i disabled the lock(setLockTimeOut(0)), my program dead there. maybe a deadlock is really happened. but why? And, if i disabled the transaction(setTransactional(false)),my program seems worked well

Message was edited by: Richie
user528204

Comments

  • 531207
    531207 Member Posts: 11
    Sorry my mistake.

    I finally found out the problem. it's because of i didn't close a EntityCursor(that's for getting the infomation of the data i would delete later).

    i guess i have to cache the result and close that cursor before the deleting operation start.
  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    I'm glad you found the problem.

    Yes, a cursor will always hold a lock for the record on which it is positioned. That provides "cursor stability" -- it ensures that no other thread or transaction will change the record. We recommend that cursors are closed as soon as possible after using them.

    Mark
This discussion has been closed.