We use Apache Sling 7 (jackrabbit-core 2.6.5) with 2 clusters on a WAS WebSphere Platform 8.5 (Java version (IBM) 1.6.0).
The configuration of the Jackrabbit repository (uses ORACLE database) is as follows: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE Repository PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 2.0//EN" "http://jackrabbit.apache.org/dtd/repository-2.0.dtd"> <Repository> <FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem"> </FileSystem> <DataStore class="org.apache.jackrabbit.core.data.FileDataStore"> </DataStore> <Security appName="Jackrabbit"> <SecurityManager class="org.apache.jackrabbit.core.DefaultSecurityManager" workspaceName="security"> </SecurityManager> <AccessManager class="org.apache.sling.jcr.jackrabbit.server.impl.security.PluggableDefaultAccessManager"> </AccessManager> <LoginModule class="org.apache.sling.jcr.jackrabbit.server.impl.security.PluggableDefaultLoginModule"> </LoginModule> </Security> <Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/> <Workspace name="${wsp.name}"> <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> </FileSystem> <PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.OraclePersistenceManager"> </PersistenceManager> <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex"> </SearchIndex> </Workspace> <Versioning rootPath="${rep.home}/version"> <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> </FileSystem> <PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.OraclePersistenceManager"> </PersistenceManager> </Versioning> <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex"> </SearchIndex> <Cluster id="{CLUSTER_ID}" syncDelay="2000"> <Journal class="org.apache.jackrabbit.core.journal.OracleDatabaseJournal"> </Journal> </Cluster> </Repository> >From time to time, even if there is no activity on the application, the SLING_LOCAL_REVISONS table remains locked, we must unlock the table and restart the WAS cluster. The lock is on a request : update SLING_LOCAL_REVISIONS set REVISION_ID = ? where JOURNAL_ID = ? To know where these updates of SLING_LOCAL_REVISIONS table came from, I modified the DatabaseJournal class to use my own ConnectionHelper class in which I add stack traces logs. The updates come from: The modification of data by a client of the application. Cluster updates using the Journal. And many updates that come from the "discovery" component. I think that the blocking occurs between these 2 last points with REVISION_ID which are sometimes identical. This is bizarre especially because the method that performs the updates is synchronized (DatabaseJournal.DatabaseRevision.set). Do you know this kind of problem and how to solve it? Thank you -- View this message in context: http://apache-sling.73963.n3.nabble.com/Lock-on-LOCAL-REVISONS-table-tp4068204.html Sent from the Sling - Users mailing list archive at Nabble.com.