Lock on LOCAL_REVISONS table

[JMR <je...@atos.net>]

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 &quot;-//The Apache Software Foundation//DTD Jackrabbit
2.0//EN&quot;
      &quot;http://jackrabbit.apache.org/dtd/repository-2.0.dtd&quot;>
<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.

Re: Lock on LOCAL_REVISONS table

[JMR <je...@atos.net>]

Hello

Indeed I had seen this problem regarding Jackrabbit, it still exists even if
a correction was made by https://issues.apache.org/jira/browse/JCR-3440.

Thank you



--
View this message in context: http://apache-sling.73963.n3.nabble.com/Lock-on-LOCAL-REVISONS-table-tp4068204p4068221.html
Sent from the Sling - Users mailing list archive at Nabble.com.

Re: Lock on LOCAL_REVISONS table

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Tue, Nov 29, 2016 at 4:39 PM, JMR <je...@atos.net> wrote:
> ...Do you know this kind of problem and how to solve it?...

Maybe someone here can help (I can't) but this looks more like a pure
Jackrabbit problem, maybe related to
https://issues.apache.org/jira/browse/JCR-3738 ?

-Bertrand