[
https://issues.apache.org/jira/browse/JCR-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899361#comment-13899361
]
Jose Carlos Campanero commented on JCR-3570:
--------------------------------------------
Something very similar to that indicated by Claudiu happens in the following
scenario: in our web application we use Jackrabbit embedded. This application
is deployed on a cluster of Weblogic: as part of its initialization process the
application checks if the repository is created, creating it through
org.apache.jackrabbit.core.config.RepositoryConfig.create otherwise. At this
time log traces similar to those shown by Claudiu originate.
The environment consists of Weblogic 10.3.4 on RHEL 5.5 and Oracle 11g.
Jackrabbit version is 2.2.11.
Given the wealth of information that can be handled and the consequent delay in
the start, initialization of the repository after the first login might be
inappropriate. Would it be possible to synchronize in some other way this
process?
> Make immediately Repository start configureable in JCAManagedConnectionFactory
> ------------------------------------------------------------------------------
>
> Key: JCR-3570
> URL: https://issues.apache.org/jira/browse/JCR-3570
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.6
> Environment: Linux jaguar 2.6.32-262.el6.x86_64 #1 SMP Sun Apr 8
> 18:38:00 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
> Jackrabbit 2.6.0 JCA deployed on JBoss AS 7.1.0.final cluster configuration
> (domain setup with 2 managed server instances on the same machine)
> Reporter: Claudiu Muresan
> Assignee: Claus Köll
> Priority: Blocker
> Fix For: 2.6.1, 2.7
>
> Attachments: JCR-3570.patch, repository_server1.xml,
> repository_server2.xml
>
>
> The 2 managed server instances are deployed jackrabbit-jca.rar archive using
> jboss cli.
> repository.xml is available for both instances at locations:
> (instance1 = server1 :
> /opt/kmp/jboss-7.1.0.Final/domain/servers/server1/data/jackrabbit)
> (instance2 = server2 :
> /opt/kmp/jboss-7.1.0.Final/domain/servers/server2/data/jackrabbit)
> The difference between the 2 repository xml files is given by the name of the
> cluster node.
> server1 is known as node1 in Jackrabbit cluster
> server2 is known as node2 in Jackrabbit cluster
> JBoss starts the deployment of jackrabbit rar archive in the same time.
> Please note that Jackrabbit tables/indexes have been created using an SQL
> script prior to jackrabbit deployment. No data is added into the tables.
> One of the managed server instances e.g. server1 is able to add the the
> implicit node type definitions as bundles into version_bundle and
> default_bundle respectively. The problem is that the other managed server is
> trying to also store the bundles and we have a referential integrity error.
> server2 instance fails with below exception:
> 12:14:11,502 ERROR
> [org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager] (MSC
> service thread 1-3) FATAL error while writing the bundle:
> deadbeef-face-babe-cafe-babecafebabe:
> java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique
> constraint (DBUSER_LOGAN.IDX_VERSION_BUNDLE_NODE_ID) violated
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445)
> [ojdbc6.jar:11.2.0.3.0]
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
> [ojdbc6.jar:11.2.0.3.0]
> at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879)
> [ojdbc6.jar:11.2.0.3.0]
> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450)
> [ojdbc6.jar:11.2.0.3.0]
> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
> [ojdbc6.jar:11.2.0.3.0]
> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3685)
> [ojdbc6.jar:11.2.0.3.0]
> at
> oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1376)
> [ojdbc6.jar:11.2.0.3.0]
> at
> org.jboss.jca.adapters.jdbc.CachedPreparedStatement.execute(CachedPreparedStatement.java:297)
> at
> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:404)
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper.execute(ConnectionHelper.java:516)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyUpdate(ConnectionHelper.java:344)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:331)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:327)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(ConnectionHelper.java:550)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.util.db.ConnectionHelper.update(ConnectionHelper.java:327)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:950)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:799)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.storeInternal(AbstractBundlePersistenceManager.java:714)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:590)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:482)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.version.InternalVersionManagerImpl.<init>(InternalVersionManagerImpl.java:174)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:492)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:311)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:589)
> [jackrabbit-core-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.jca.JCARepositoryManager.createNonTransientRepository(JCARepositoryManager.java:124)
> [jackrabbit-jca-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.jca.JCARepositoryManager.createRepository(JCARepositoryManager.java:79)
> [jackrabbit-jca-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createRepository(JCAManagedConnectionFactory.java:209)
> [jackrabbit-jca-2.6.0.jar:2.6.0]
> at
> org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createConnectionFactory(JCAManagedConnectionFactory.java:147)
> [jackrabbit-jca-2.6.0.jar:2.6.0]
> How can we overcome this situation?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
