Bug 37732 - Resource Locks Aren't Persisted Using LDAP
Summary: Resource Locks Aren't Persisted Using LDAP
Status: NEW
Alias: None
Product: Slide
Classification: Unclassified
Component: Stores (show other bugs)
Version: Nightly
Hardware: PC Windows 2000
: P2 normal (vote)
Target Milestone: ---
Assignee: Slide Developer List
Depends on:
Reported: 2005-12-01 08:20 UTC by Damien Bastin
Modified: 2005-11-30 23:24 UTC (History)
0 users

Inserts URI into DB when putLock() called (66.74 KB, text/plain)
2005-12-01 08:24 UTC, Damien Bastin

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Bastin 2005-12-01 08:20:04 UTC
Locks on resources are lost when you restart the WebDAV server if you dont store
user info in the database. 

The lock table is not being written to by when using LDAP for user information.
This is because the insert command in the StandardRBDMSAdapter checks for users
in the slide database. 

When you are using an external source for users and roles (i.e. LDAP) there is
nothing stored in the database except for what is defined in the Domain.xml.

This problem may effect other parts of the system including LINKS, LABELs and
potentially ACLs.

To reproduce the problem:

    * Log into WebDAV as a user in LDAP store.
    * Use a WebDAV client to lock a resource.
    * Restart WebDAV server.
    * Refresh the view, the resource will be unlocked. 

To fix the problem:

    * Insert /users/support into the WebDAV URI table.
    * Log into WebDAV.
    * Use a WebDAV client to lock a resource.
    * Restart WebDAV server.
    * Refresh the view, the resource will be locked. 

Here is the solution in code. You can change the StandardRDBMSAdapter like so:

public void putLock(Connection connection, Uri uri, NodeLock lock) throws
ServiceAccessException {
        PreparedStatement statement = null;
        try {
            int inheritable = lock.isInheritable() ? 1 : 0;
            int exclusive = lock.isExclusive() ? 1 : 0;
            long lockid = assureUriId(connection, lock.getLockId());

            populateUriTableWithUserUri(connection, lock);

            statement = connection.prepareStatement(
                    "insert into LOCKS
" +
                    "select ?, object.URI_ID, subject.URI_ID, type.URI_ID, ?, ?,
?, ? " +
                    "from URI object, URI subject, URI type WHERE
object.URI_STRING=? and subject.URI_STRING=? and type.URI_STRING=?");
            statement.setLong(1, lockid);
            statement.setLong(2, lock.getExpirationDate().getTime());
            statement.setInt(3, inheritable);
            statement.setInt(4, exclusive);
            statement.setString(5, lock.getOwnerInfo());
            statement.setString(6, lock.getObjectUri());
            statement.setString(7, lock.getSubjectUri());
            statement.setString(8, lock.getTypeUri());

            if (statement.getUpdateCount() == 0) {
                throw new ServiceAccessException(service, "Insert of the lock
failed as the user could not be found in the URI table.");
        } catch (SQLException e) {
            throw createException(e, uri.toString());
        } finally {

    private void populateUriTableWithUserUri(Connection connection, NodeLock
lock) throws SQLException {
        PreparedStatement statement = connection.prepareStatement("select URI_ID
from URI where URI_STRING = ?");
        statement.setString(1, lock.getSubjectUri());
        ResultSet results = statement.getResultSet();
        boolean hasNextRow = results.next();
        if (hasNextRow == false) {
            insertUri(connection, lock.getSubjectUri());

    private void insertUri(Connection connection, String subjectUri) throws
SQLException {
        PreparedStatement statement = connection.prepareStatement("Insert into
URI (URI_STRING) values (?)");
        statement.setString(1, subjectUri);

Comment 1 Damien Bastin 2005-12-01 08:24:07 UTC
Created attachment 17100 [details]
Inserts URI into DB when putLock() called

Note that this attachment also contains the fix to bug id: 37583