[bdbxml] Java dbxml: Differences between locks, lockers, lock objects? how do you reclaim them?
"Adrien Lamoureux" <[email protected]> Fri, 2 Sep 2005 16:12:11 -0400
| Newsgroups | gmane.comp.db.dbxml.general |
|---|---|
| Message-ID | <[email protected]> |
Hello,
I have the perspective of a Java developer using the Java BDXML API, where the implementation details of Berkeley DB are hidden from me, so I don't have a good understanding of when exactly bdxml locks/unlocks and what the difference is between a "lock", a "locker" or a "lock object" and also the difference between a "deadlock" and "conflict".
I found out that this particular code fragment causes a self-deadlock(even though it detects as a conflict!):
XmlQueryContext qc = theManager.createQueryContext();
XmlModify mod = theManager.createModify();
..
XmlResults allDocsSel = theManager.query(xQueryDocSelection,qc);
XmlUpdateContext uc = theManager.createUpdateContext();
mod.execute(allDocsSel);
allDocsSel.delete();
uc.delete();
When I instruct the query context to use live data with lazy evaluation, and iterate over each value in XmlResults, the self-deadlock is avoided. I also found out that the "delete" statements were not necessary to avoid deadlock.
XmlQueryContext qc = theManager.createQueryContext(XmlQueryContext.LiveValues,XmlQueryContext.Lazy);
XmlModify mod = theManager.createModify();
..
XmlResults allDocsSel = theManager.query(xQueryDocSelection,qc);
XmlUpdateContext uc = theManager.createUpdateContext();
XmlValue thisValue = null;
while((thisValue = allDocsSel.next())!=null)
{
mod.execute(thisValue,qc,uc);
thisValue.delete();
}
allDocsSel.delete();
uc.delete();
I've synchronized my methods to further prevent any kind of internal deadlock and it appears to function until I seem to run out of locker entries!
How do I reclaim locker entries/locks/lock objects? I assumed they would "free themselves up" after a certain period of time. I've read that XmlManager and XmlContainer hold locks, so I closed and deleted them after every use, but the locks are still being used up...
Thanks.
Adrien