Robert,
The locks managed by lock-acquire and lock-release are user-level locks,
and are always explicit. Their intended use is for content-management
apps: a trivial example is the webdav server, which uses user-level
locks to implement the webdav protocol. If you aren't already using the
lock APIs as part of your application, then it's very unlikely that you
need to worry about user-level locks.
At a lower level, update queries generate and release their own
transaction-level locks, automatically. These transaction-level locks
have no direct relationship with user-visible locks. The names are
admittedly confusing, but under normal operation the transaction-level
locks are completely invisible.
There's more information about both types of locks in our documentation.
So your described behavior with JUnit almost certainly didn't involve
user-level locks. However, it's not at all clear to me that your stalled
JUnit test had anything to do with transaction-level locking either. If
I had observed the behavior you describe, I would have gone to the Host
Status page in the admin server and looked for long-running queries, by
checking the "Oldest Request" column in the App Server table. Then I'd
click on the name of the app server with the oldest request, taking me
to the server status page. On that page, I'd use the "Show More" button
to examine all the running requests, and identify the oldest one
(probably your JUnit ad-hoc query). At that point you could try to
cancel it.
I hope that helps. If not, and if you can reproduce the problem, I'd
recommend contacting support. If there's a server issue to report, they
can help you with that.
-- Mike
On 2009-09-25 08:15, Runstein, Robert E. (Contr) (IS) wrote:
Thanks, Mike. RTFM is always good advice.
Will xdmp:lock-release release a lock that was not created by an explicit call
to xdmp:lock-acquire? I was running a series of JUnit tests using ad hoc
queries via XDBC while someone else was running RecordLoader and maxing out the
CPU. There was no commonality between the test documents and the documents
being processed by RecordLoader. My tests hung so I killed the JUnit process.
When the RecordLoader finished and CPU utilization went back to nominal I tried
to rerun my tests. The first test hung trying to delete one of the test
documents inserted by the previous test run (by the same user). I killed the
test process and tried to delete the document as the Admin user via cq and this
hung as well.
Not knowing about the xdbc:release function, I restarted the database to clear
the lock. My tests do not explicitly call xdmp:lock-acquire.
I'm wondering a few things:
1. Would xdmp:lock-release have released the lock?
2. How did I end up with the lock in the first place? (When the doc was
inserted did the lock not get released because of the load on the server?)
3. How can I avoid this in the future? Can I set a timeout for how long
another process should wait to acquire the lock before it errors out?
I looked in the error log and did not see any thing that indicated that a
deadlock occurred.
Bob
Is there a way to find documents that are locked using the Admin Console? If
not, is there a query than can be run in cq to find locked documents?
http://developer.marklogic.com/pubs/4.1/apidocs/Ext-9.html#xdmp:document-locks
says that it "Returns the locks for all documents and directories in the database if
no parameter is given."
-- Mike
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
