You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by dainius rygelis <da...@pitchpointsolutions.com> on 2007/12/03 23:43:05 UTC
autcommit in DatabaseJournal.append
Hi, we're fairly new to jackrabbit and are evaluating it for use in a highly available deployment. We're looking at using the database journal but are encountering problems. Jackrabbit has been deployed as resource adapter on glassfish and works great until we attempt to use the database journal.
The jackrabbit resource adapter is enlisted in a container managed transaction through a resource environment reference in a session bean. When the container attempts to commit or rollback the transaction an error is thrown because DatabaseJournal.append has called connection.commit and attempted to set autocommit to true. Are we using DatabaseJournal incorrectly?
Here's the snippet of our config that's causing the problem.
<Cluster id="node1">
<Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
<param name="revision" value="${rep.home}/revision.log" />
<param name="driver" value="com.mysql.jdbc.Driver" />
<param name="url" value="jdbc:mysql://localhost/######" />
<param name="user" value="######" />
<param name="password" value="#######" />
<param name="schema" value="mysql" />
<param name="schemaObjectPrefix" value="global_" />
</Journal>
</Cluster>
Here's the relevant test code from the session bean..
@Stateless
@TransactionManagement(value = TransactionManagementType.CONTAINER)
public class JackrabbitFacadeBean implements JackrabbitFacadeLocal {
@Resource(name = "jcr/repository", shareable = true, type = Repository.class)
private Repository repository;
......
......
......
public String saveDocument(String parentNode, String document) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("saveDocument(" + parentNode + ", " + document + ") - start");
}
SimpleCredentials credentials = new SimpleCredentials("######", "######".toCharArray());
String uuid = null;
try {
InputStream stream = new ByteArrayInputStream(document.getBytes());
Session session = repository.login(credentials);
Node root = session.getRootNode();
dump(root);
if (!root.hasNode(parentNode)) {
Node node = root.addNode(parentNode, "nt:unstructured");
uuid = node.getPath();
}else{
Node node = root.getNode(parentNode);
uuid = node.getPath();
}
session.importXML("/" + parentNode, stream, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
stream.close();
session.save();
dump(root);
session.logout();
} catch (Exception e) {
LOGGER.fatal(e.getLocalizedMessage(), e);
throw new RuntimeException(e);
}
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("saveDocument() - end return value=" + uuid);
}
return uuid;
}
and the stack trace...
2007-12-03 16:56:05,WARN,org.apache.jackrabbit.core.journal.DatabaseJournal,httpSSLWorkerThread-8080-1 Error while rolling back connection: Can't call rollback when autocommit=true
2007-12-03 16:56:05,ERROR,org.apache.jackrabbit.core.cluster.ClusterNode,httpSSLWorkerThread-8080-1 Unable to commit log entry.
org.apache.jackrabbit.core.journal.JournalException: Unable to append revision 4.
at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:322)
at org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:614)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:725)
at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:162)
at org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:475)
at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:177)
at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339)
at org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy24.saveDocument(Unknown Source)
at pps.jackrabbit.demo.web.bean.JackRabbitTestBean.submit(JackRabbitTestBean.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: java.sql.SQLException: Can't call commit when autocommit=true
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:914)
at com.mysql.jdbc.Connection.commit(Connection.java:2273)
at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:311)
... 67 more
Thanks for your help,
Dainius
Re: autcommit in DatabaseJournal.append
Posted by Dominique Pfister <do...@day.com>.
Hi,
for quite some time, the database journal closes a connection if an
error occurs and should therefore recover gracefully from this
situation. What version of jackrabbit are you using?
Kind regards
Dominique
On 15/01/2008, Brett Connor <co...@axxia.com> wrote:
>
> We have a related issue wrt the connection used for the journal table. In
> some of our deployments the database (ms sqlserver) is taken down for a
> while overnight, I believe to backup. The rest of our application recovers
> from this when the database is available again, but the Jackrabbit cluster
> journalling doesn't seem to, there are continuous log entries appearing:
>
> org.apache.jackrabbit.core.cluster.ClusterNode
> Periodic sync of journal failed: Unable to return record iterater.
>
> This would be another advantage of using the appserver connection pool (we
> use Jackrabbit in JBoss).
> Is there another way to recover from this without bouncing the appserver?
> Thanks
>
> Brett
>
> -----Original Message-----
>
> Hi Dominique,
>
> Thanks for the quick resolution.
>
> Just out of curiosity, what's the performance difference between the way
> jackrabbit has implemented sql execution vs
> calling...
>
> Connection conn = DataSource.getConnection();
> PreparedStatement stmt = connection.prepareStatement(sqlString);
>
> .....
>
> rs.close();
> stmt.close();
> connection.close();
>
> every time to execute a sql statement?
>
> The thinking being that the above approach should perform just as quickly or
> quicker on the container because the driver or the container usually caches
> prepared statements and provides validated connections from a pool. We
> haven't yet done any testing ourselves to check if there's a difference.
>
> Thanks,
> Dainius
>
> -----Original Message-----
> From: Dominique Pfister [mailto:dominique.pfister@day.com]
> Sent: December-04-07 11:09 AM
> To: users@jackrabbit.apache.org
> Subject: Re: autcommit in DatabaseJournal.append
>
> Hi Dainius,
>
> I could easily reproduce your scenario with a clustered setup and MySQL
> backend. Apparently, other backends are more tolerant when calling commit()
> on a connection that is already in auto-commit mode.
> I filed a JIRA issue for this:
>
> https://issues.apache.org/jira/browse/JCR-1254
>
> and fixed it in the main trunk. Thank you very much for reporting!
>
> On 04/12/2007, dainius rygelis <da...@pitchpointsolutions.com>
> wrote:
> > Hi Dominique,
> >
> > Yes, we're using 1.3.3.
> >
> > Two more questions...
> > Are the DatabaseJournal sql operations supposed in their own transaction?
>
> Yes.
>
> > Also, why the use of a single connection vs obtaining a new one when
> > needed from the connection pool supported datasource in the
> > DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and
> > BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations?
>
> There are PreparedStatements inside these classes that one would have to
> prepare every time a connection is obtained from the pool.
>
> --
> View this message in context: http://www.nabble.com/autcommit-in-DatabaseJournal.append-tp14140740p14839847.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
RE: autcommit in DatabaseJournal.append
Posted by Brett Connor <co...@axxia.com>.
We have a related issue wrt the connection used for the journal table. In
some of our deployments the database (ms sqlserver) is taken down for a
while overnight, I believe to backup. The rest of our application recovers
from this when the database is available again, but the Jackrabbit cluster
journalling doesn't seem to, there are continuous log entries appearing:
org.apache.jackrabbit.core.cluster.ClusterNode
Periodic sync of journal failed: Unable to return record iterater.
This would be another advantage of using the appserver connection pool (we
use Jackrabbit in JBoss).
Is there another way to recover from this without bouncing the appserver?
Thanks
Brett
-----Original Message-----
Hi Dominique,
Thanks for the quick resolution.
Just out of curiosity, what's the performance difference between the way
jackrabbit has implemented sql execution vs
calling...
Connection conn = DataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(sqlString);
.....
rs.close();
stmt.close();
connection.close();
every time to execute a sql statement?
The thinking being that the above approach should perform just as quickly or
quicker on the container because the driver or the container usually caches
prepared statements and provides validated connections from a pool. We
haven't yet done any testing ourselves to check if there's a difference.
Thanks,
Dainius
-----Original Message-----
From: Dominique Pfister [mailto:dominique.pfister@day.com]
Sent: December-04-07 11:09 AM
To: users@jackrabbit.apache.org
Subject: Re: autcommit in DatabaseJournal.append
Hi Dainius,
I could easily reproduce your scenario with a clustered setup and MySQL
backend. Apparently, other backends are more tolerant when calling commit()
on a connection that is already in auto-commit mode.
I filed a JIRA issue for this:
https://issues.apache.org/jira/browse/JCR-1254
and fixed it in the main trunk. Thank you very much for reporting!
On 04/12/2007, dainius rygelis <da...@pitchpointsolutions.com>
wrote:
> Hi Dominique,
>
> Yes, we're using 1.3.3.
>
> Two more questions...
> Are the DatabaseJournal sql operations supposed in their own transaction?
Yes.
> Also, why the use of a single connection vs obtaining a new one when
> needed from the connection pool supported datasource in the
> DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and
> BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations?
There are PreparedStatements inside these classes that one would have to
prepare every time a connection is obtained from the pool.
--
View this message in context: http://www.nabble.com/autcommit-in-DatabaseJournal.append-tp14140740p14839847.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
RE: autcommit in DatabaseJournal.append
Posted by dainius rygelis <da...@pitchpointsolutions.com>.
Hi Dominique,
Thanks for the quick resolution.
Just out of curiosity, what's the performance difference between the way jackrabbit has implemented sql execution vs
calling...
Connection conn = DataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(sqlString);
.....
rs.close();
stmt.close();
connection.close();
every time to execute a sql statement?
The thinking being that the above approach should perform just as quickly or quicker on the container because the driver or the container usually caches prepared statements and provides validated connections from a pool. We haven't yet done any testing ourselves to check if there's a difference.
Thanks,
Dainius
-----Original Message-----
From: Dominique Pfister [mailto:dominique.pfister@day.com]
Sent: December-04-07 11:09 AM
To: users@jackrabbit.apache.org
Subject: Re: autcommit in DatabaseJournal.append
Hi Dainius,
I could easily reproduce your scenario with a clustered setup and MySQL backend. Apparently, other backends are more tolerant when calling commit() on a connection that is already in auto-commit mode.
I filed a JIRA issue for this:
https://issues.apache.org/jira/browse/JCR-1254
and fixed it in the main trunk. Thank you very much for reporting!
On 04/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> Hi Dominique,
>
> Yes, we're using 1.3.3.
>
> Two more questions...
> Are the DatabaseJournal sql operations supposed in their own transaction?
Yes.
> Also, why the use of a single connection vs obtaining a new one when needed from the connection pool supported datasource in the DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations?
There are PreparedStatements inside these classes that one would have to prepare every time a connection is obtained from the pool.
Kind regards
Dominique
> Appreciate your help,
> Dainius
>
> -----Original Message-----
> From: Dominique Pfister [mailto:dominique.pfister@day.com]
> Sent: December-04-07 4:15 AM
> To: users@jackrabbit.apache.org
> Subject: Re: autcommit in DatabaseJournal.append
>
> Hi Dainius,
>
> your configuration looks fine to me and I don't think you're using DatabaseJournal incorrectly. You're using Jackrabbit 1.3.3, right?
> When appending new entries to the journal, the order of calls on the
> journal and corresponding actions on the database connection is as
> follows:
>
> Journal Connection
>
> lock() autocommit=false
> append() commit or rollback
> unlock() autocommit=true
>
> In your stack trace commit() is called while the connection is in autocommit mode, which implies that some other component already unlocked the journal. I'm going to investigate the calls made on behalf of the journal when a transaction - updating both a workspace and the versioning space - is committed.
>
> Kind regards
> Dominique
>
> On 03/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> > Hi, we're fairly new to jackrabbit and are evaluating it for use in a highly available deployment. We're looking at using the database journal but are encountering problems. Jackrabbit has been deployed as resource adapter on glassfish and works great until we attempt to use the database journal.
> > The jackrabbit resource adapter is enlisted in a container managed transaction through a resource environment reference in a session bean. When the container attempts to commit or rollback the transaction an error is thrown because DatabaseJournal.append has called connection.commit and attempted to set autocommit to true. Are we using DatabaseJournal incorrectly?
> >
> > Here's the snippet of our config that's causing the problem.
> > <Cluster id="node1">
> > <Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
> > <param name="revision" value="${rep.home}/revision.log" />
> > <param name="driver" value="com.mysql.jdbc.Driver" />
> > <param name="url" value="jdbc:mysql://localhost/######" />
> > <param name="user" value="######" />
> > <param name="password" value="#######" />
> > <param name="schema" value="mysql" />
> > <param name="schemaObjectPrefix" value="global_" />
> > </Journal>
> > </Cluster>
> >
> >
> > Here's the relevant test code from the session bean..
> >
> > @Stateless
> > @TransactionManagement(value = TransactionManagementType.CONTAINER)
> > public class JackrabbitFacadeBean implements JackrabbitFacadeLocal {
> >
> > @Resource(name = "jcr/repository", shareable = true, type = Repository.class)
> > private Repository repository;
> >
> > ......
> > ......
> > ......
> >
> > public String saveDocument(String parentNode, String document) {
> > if (LOGGER.isDebugEnabled()) {
> > LOGGER.debug("saveDocument(" + parentNode + ", " + document + ") - start");
> > }
> > SimpleCredentials credentials = new SimpleCredentials("######", "######".toCharArray());
> > String uuid = null;
> > try {
> > InputStream stream = new ByteArrayInputStream(document.getBytes());
> > Session session = repository.login(credentials);
> > Node root = session.getRootNode();
> > dump(root);
> > if (!root.hasNode(parentNode)) {
> > Node node = root.addNode(parentNode, "nt:unstructured");
> > uuid = node.getPath();
> > }else{
> > Node node = root.getNode(parentNode);
> > uuid = node.getPath();
> > }
> > session.importXML("/" + parentNode, stream, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
> > stream.close();
> > session.save();
> > dump(root);
> > session.logout();
> > } catch (Exception e) {
> > LOGGER.fatal(e.getLocalizedMessage(), e);
> > throw new RuntimeException(e);
> > }
> > if (LOGGER.isDebugEnabled()) {
> > LOGGER.debug("saveDocument() - end return value=" + uuid);
> > }
> > return uuid;
> > }
> >
> > and the stack trace...
> >
> > 2007-12-03
> > 16:56:05,WARN,org.apache.jackrabbit.core.journal.DatabaseJournal,htt
> > pS
> > SLWorkerThread-8080-1 Error while rolling back connection: Can't
> > call rollback when autocommit=true
> > 2007-12-03 16:56:05,ERROR,org.apache.jackrabbit.core.cluster.ClusterNode,httpSSLWorkerThread-8080-1 Unable to commit log entry.
> > org.apache.jackrabbit.core.journal.JournalException: Unable to append revision 4.
> > at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:322)
> > at org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
> > at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:614)
> > at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:725)
> > at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:162)
> > at org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:475)
> > at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:177)
> > at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339)
> > at org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
> > at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
> > at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
> > at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
> > at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
> > at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
> > at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
> > at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
> > at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
> > at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
> > at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
> > at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
> > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
> > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
> > at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
> > at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
> > at $Proxy24.saveDocument(Unknown Source)
> > at pps.jackrabbit.demo.web.bean.JackRabbitTestBean.submit(JackRabbitTestBean.java:42)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
> > at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
> > at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
> > at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
> > at javax.faces.component.UICommand.broadcast(UICommand.java:383)
> > at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
> > at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
> > at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> > at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
> > at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
> > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> > at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
> > at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
> > at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
> > at
> > com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSL
> > Wo
> > rkerThread.java:106) Caused by: java.sql.SQLException: Can't call
> > commit when autocommit=true
> > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:914)
> > at com.mysql.jdbc.Connection.commit(Connection.java:2273)
> > at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:311)
> > ... 67 more
> >
> > Thanks for your help,
> > Dainius
> >
>
>
Re: autcommit in DatabaseJournal.append
Posted by Dominique Pfister <do...@day.com>.
Hi Dainius,
I could easily reproduce your scenario with a clustered setup and
MySQL backend. Apparently, other backends are more tolerant when
calling commit() on a connection that is already in auto-commit mode.
I filed a JIRA issue for this:
https://issues.apache.org/jira/browse/JCR-1254
and fixed it in the main trunk. Thank you very much for reporting!
On 04/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> Hi Dominique,
>
> Yes, we're using 1.3.3.
>
> Two more questions...
> Are the DatabaseJournal sql operations supposed in their own transaction?
Yes.
> Also, why the use of a single connection vs obtaining a new one when needed from the connection pool supported datasource in the DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations?
There are PreparedStatements inside these classes that one would have
to prepare every time a connection is obtained from the pool.
Kind regards
Dominique
> Appreciate your help,
> Dainius
>
> -----Original Message-----
> From: Dominique Pfister [mailto:dominique.pfister@day.com]
> Sent: December-04-07 4:15 AM
> To: users@jackrabbit.apache.org
> Subject: Re: autcommit in DatabaseJournal.append
>
> Hi Dainius,
>
> your configuration looks fine to me and I don't think you're using DatabaseJournal incorrectly. You're using Jackrabbit 1.3.3, right?
> When appending new entries to the journal, the order of calls on the journal and corresponding actions on the database connection is as
> follows:
>
> Journal Connection
>
> lock() autocommit=false
> append() commit or rollback
> unlock() autocommit=true
>
> In your stack trace commit() is called while the connection is in autocommit mode, which implies that some other component already unlocked the journal. I'm going to investigate the calls made on behalf of the journal when a transaction - updating both a workspace and the versioning space - is committed.
>
> Kind regards
> Dominique
>
> On 03/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> > Hi, we're fairly new to jackrabbit and are evaluating it for use in a highly available deployment. We're looking at using the database journal but are encountering problems. Jackrabbit has been deployed as resource adapter on glassfish and works great until we attempt to use the database journal.
> > The jackrabbit resource adapter is enlisted in a container managed transaction through a resource environment reference in a session bean. When the container attempts to commit or rollback the transaction an error is thrown because DatabaseJournal.append has called connection.commit and attempted to set autocommit to true. Are we using DatabaseJournal incorrectly?
> >
> > Here's the snippet of our config that's causing the problem.
> > <Cluster id="node1">
> > <Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
> > <param name="revision" value="${rep.home}/revision.log" />
> > <param name="driver" value="com.mysql.jdbc.Driver" />
> > <param name="url" value="jdbc:mysql://localhost/######" />
> > <param name="user" value="######" />
> > <param name="password" value="#######" />
> > <param name="schema" value="mysql" />
> > <param name="schemaObjectPrefix" value="global_" />
> > </Journal>
> > </Cluster>
> >
> >
> > Here's the relevant test code from the session bean..
> >
> > @Stateless
> > @TransactionManagement(value = TransactionManagementType.CONTAINER)
> > public class JackrabbitFacadeBean implements JackrabbitFacadeLocal {
> >
> > @Resource(name = "jcr/repository", shareable = true, type = Repository.class)
> > private Repository repository;
> >
> > ......
> > ......
> > ......
> >
> > public String saveDocument(String parentNode, String document) {
> > if (LOGGER.isDebugEnabled()) {
> > LOGGER.debug("saveDocument(" + parentNode + ", " + document + ") - start");
> > }
> > SimpleCredentials credentials = new SimpleCredentials("######", "######".toCharArray());
> > String uuid = null;
> > try {
> > InputStream stream = new ByteArrayInputStream(document.getBytes());
> > Session session = repository.login(credentials);
> > Node root = session.getRootNode();
> > dump(root);
> > if (!root.hasNode(parentNode)) {
> > Node node = root.addNode(parentNode, "nt:unstructured");
> > uuid = node.getPath();
> > }else{
> > Node node = root.getNode(parentNode);
> > uuid = node.getPath();
> > }
> > session.importXML("/" + parentNode, stream, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
> > stream.close();
> > session.save();
> > dump(root);
> > session.logout();
> > } catch (Exception e) {
> > LOGGER.fatal(e.getLocalizedMessage(), e);
> > throw new RuntimeException(e);
> > }
> > if (LOGGER.isDebugEnabled()) {
> > LOGGER.debug("saveDocument() - end return value=" + uuid);
> > }
> > return uuid;
> > }
> >
> > and the stack trace...
> >
> > 2007-12-03
> > 16:56:05,WARN,org.apache.jackrabbit.core.journal.DatabaseJournal,httpS
> > SLWorkerThread-8080-1 Error while rolling back connection: Can't call
> > rollback when autocommit=true
> > 2007-12-03 16:56:05,ERROR,org.apache.jackrabbit.core.cluster.ClusterNode,httpSSLWorkerThread-8080-1 Unable to commit log entry.
> > org.apache.jackrabbit.core.journal.JournalException: Unable to append revision 4.
> > at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:322)
> > at org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
> > at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:614)
> > at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:725)
> > at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:162)
> > at org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:475)
> > at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:177)
> > at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339)
> > at org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
> > at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
> > at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
> > at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
> > at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
> > at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
> > at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
> > at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
> > at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
> > at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
> > at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
> > at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
> > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
> > at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
> > at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
> > at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
> > at $Proxy24.saveDocument(Unknown Source)
> > at pps.jackrabbit.demo.web.bean.JackRabbitTestBean.submit(JackRabbitTestBean.java:42)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
> > at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
> > at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
> > at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
> > at javax.faces.component.UICommand.broadcast(UICommand.java:383)
> > at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
> > at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
> > at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> > at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
> > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
> > at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
> > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> > at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> > at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> > at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
> > at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
> > at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
> > at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
> > at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
> > at
> > com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWo
> > rkerThread.java:106) Caused by: java.sql.SQLException: Can't call
> > commit when autocommit=true
> > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:914)
> > at com.mysql.jdbc.Connection.commit(Connection.java:2273)
> > at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:311)
> > ... 67 more
> >
> > Thanks for your help,
> > Dainius
> >
>
>
RE: autcommit in DatabaseJournal.append
Posted by dainius rygelis <da...@pitchpointsolutions.com>.
Hi Dominique,
Yes, we're using 1.3.3.
Two more questions...
Are the DatabaseJournal sql operations supposed in their own transaction?
Also, why the use of a single connection vs obtaining a new one when needed from the connection pool supported datasource in the DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations?
Appreciate your help,
Dainius
-----Original Message-----
From: Dominique Pfister [mailto:dominique.pfister@day.com]
Sent: December-04-07 4:15 AM
To: users@jackrabbit.apache.org
Subject: Re: autcommit in DatabaseJournal.append
Hi Dainius,
your configuration looks fine to me and I don't think you're using DatabaseJournal incorrectly. You're using Jackrabbit 1.3.3, right?
When appending new entries to the journal, the order of calls on the journal and corresponding actions on the database connection is as
follows:
Journal Connection
lock() autocommit=false
append() commit or rollback
unlock() autocommit=true
In your stack trace commit() is called while the connection is in autocommit mode, which implies that some other component already unlocked the journal. I'm going to investigate the calls made on behalf of the journal when a transaction - updating both a workspace and the versioning space - is committed.
Kind regards
Dominique
On 03/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> Hi, we're fairly new to jackrabbit and are evaluating it for use in a highly available deployment. We're looking at using the database journal but are encountering problems. Jackrabbit has been deployed as resource adapter on glassfish and works great until we attempt to use the database journal.
> The jackrabbit resource adapter is enlisted in a container managed transaction through a resource environment reference in a session bean. When the container attempts to commit or rollback the transaction an error is thrown because DatabaseJournal.append has called connection.commit and attempted to set autocommit to true. Are we using DatabaseJournal incorrectly?
>
> Here's the snippet of our config that's causing the problem.
> <Cluster id="node1">
> <Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
> <param name="revision" value="${rep.home}/revision.log" />
> <param name="driver" value="com.mysql.jdbc.Driver" />
> <param name="url" value="jdbc:mysql://localhost/######" />
> <param name="user" value="######" />
> <param name="password" value="#######" />
> <param name="schema" value="mysql" />
> <param name="schemaObjectPrefix" value="global_" />
> </Journal>
> </Cluster>
>
>
> Here's the relevant test code from the session bean..
>
> @Stateless
> @TransactionManagement(value = TransactionManagementType.CONTAINER)
> public class JackrabbitFacadeBean implements JackrabbitFacadeLocal {
>
> @Resource(name = "jcr/repository", shareable = true, type = Repository.class)
> private Repository repository;
>
> ......
> ......
> ......
>
> public String saveDocument(String parentNode, String document) {
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("saveDocument(" + parentNode + ", " + document + ") - start");
> }
> SimpleCredentials credentials = new SimpleCredentials("######", "######".toCharArray());
> String uuid = null;
> try {
> InputStream stream = new ByteArrayInputStream(document.getBytes());
> Session session = repository.login(credentials);
> Node root = session.getRootNode();
> dump(root);
> if (!root.hasNode(parentNode)) {
> Node node = root.addNode(parentNode, "nt:unstructured");
> uuid = node.getPath();
> }else{
> Node node = root.getNode(parentNode);
> uuid = node.getPath();
> }
> session.importXML("/" + parentNode, stream, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
> stream.close();
> session.save();
> dump(root);
> session.logout();
> } catch (Exception e) {
> LOGGER.fatal(e.getLocalizedMessage(), e);
> throw new RuntimeException(e);
> }
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("saveDocument() - end return value=" + uuid);
> }
> return uuid;
> }
>
> and the stack trace...
>
> 2007-12-03
> 16:56:05,WARN,org.apache.jackrabbit.core.journal.DatabaseJournal,httpS
> SLWorkerThread-8080-1 Error while rolling back connection: Can't call
> rollback when autocommit=true
> 2007-12-03 16:56:05,ERROR,org.apache.jackrabbit.core.cluster.ClusterNode,httpSSLWorkerThread-8080-1 Unable to commit log entry.
> org.apache.jackrabbit.core.journal.JournalException: Unable to append revision 4.
> at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:322)
> at org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
> at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:614)
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:725)
> at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:162)
> at org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:475)
> at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:177)
> at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339)
> at org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
> at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
> at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
> at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
> at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
> at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
> at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
> at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
> at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
> at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
> at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
> at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
> at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
> at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
> at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
> at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
> at $Proxy24.saveDocument(Unknown Source)
> at pps.jackrabbit.demo.web.bean.JackRabbitTestBean.submit(JackRabbitTestBean.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
> at javax.faces.component.UICommand.broadcast(UICommand.java:383)
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
> at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
> at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
> at
> com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWo
> rkerThread.java:106) Caused by: java.sql.SQLException: Can't call
> commit when autocommit=true
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:914)
> at com.mysql.jdbc.Connection.commit(Connection.java:2273)
> at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:311)
> ... 67 more
>
> Thanks for your help,
> Dainius
>
Re: autcommit in DatabaseJournal.append
Posted by Dominique Pfister <do...@day.com>.
Hi Dainius,
your configuration looks fine to me and I don't think you're using
DatabaseJournal incorrectly. You're using Jackrabbit 1.3.3, right?
When appending new entries to the journal, the order of calls on the
journal and corresponding actions on the database connection is as
follows:
Journal Connection
lock() autocommit=false
append() commit or rollback
unlock() autocommit=true
In your stack trace commit() is called while the connection is in
autocommit mode, which implies that some other component already
unlocked the journal. I'm going to investigate the calls made on
behalf of the journal when a transaction - updating both a workspace
and the versioning space - is committed.
Kind regards
Dominique
On 03/12/2007, dainius rygelis <da...@pitchpointsolutions.com> wrote:
> Hi, we're fairly new to jackrabbit and are evaluating it for use in a highly available deployment. We're looking at using the database journal but are encountering problems. Jackrabbit has been deployed as resource adapter on glassfish and works great until we attempt to use the database journal.
> The jackrabbit resource adapter is enlisted in a container managed transaction through a resource environment reference in a session bean. When the container attempts to commit or rollback the transaction an error is thrown because DatabaseJournal.append has called connection.commit and attempted to set autocommit to true. Are we using DatabaseJournal incorrectly?
>
> Here's the snippet of our config that's causing the problem.
> <Cluster id="node1">
> <Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
> <param name="revision" value="${rep.home}/revision.log" />
> <param name="driver" value="com.mysql.jdbc.Driver" />
> <param name="url" value="jdbc:mysql://localhost/######" />
> <param name="user" value="######" />
> <param name="password" value="#######" />
> <param name="schema" value="mysql" />
> <param name="schemaObjectPrefix" value="global_" />
> </Journal>
> </Cluster>
>
>
> Here's the relevant test code from the session bean..
>
> @Stateless
> @TransactionManagement(value = TransactionManagementType.CONTAINER)
> public class JackrabbitFacadeBean implements JackrabbitFacadeLocal {
>
> @Resource(name = "jcr/repository", shareable = true, type = Repository.class)
> private Repository repository;
>
> ......
> ......
> ......
>
> public String saveDocument(String parentNode, String document) {
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("saveDocument(" + parentNode + ", " + document + ") - start");
> }
> SimpleCredentials credentials = new SimpleCredentials("######", "######".toCharArray());
> String uuid = null;
> try {
> InputStream stream = new ByteArrayInputStream(document.getBytes());
> Session session = repository.login(credentials);
> Node root = session.getRootNode();
> dump(root);
> if (!root.hasNode(parentNode)) {
> Node node = root.addNode(parentNode, "nt:unstructured");
> uuid = node.getPath();
> }else{
> Node node = root.getNode(parentNode);
> uuid = node.getPath();
> }
> session.importXML("/" + parentNode, stream, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW);
> stream.close();
> session.save();
> dump(root);
> session.logout();
> } catch (Exception e) {
> LOGGER.fatal(e.getLocalizedMessage(), e);
> throw new RuntimeException(e);
> }
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("saveDocument() - end return value=" + uuid);
> }
> return uuid;
> }
>
> and the stack trace...
>
> 2007-12-03 16:56:05,WARN,org.apache.jackrabbit.core.journal.DatabaseJournal,httpSSLWorkerThread-8080-1 Error while rolling back connection: Can't call rollback when autocommit=true
> 2007-12-03 16:56:05,ERROR,org.apache.jackrabbit.core.cluster.ClusterNode,httpSSLWorkerThread-8080-1 Unable to commit log entry.
> org.apache.jackrabbit.core.journal.JournalException: Unable to append revision 4.
> at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:322)
> at org.apache.jackrabbit.core.journal.AppendRecord.update(AppendRecord.java:251)
> at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCommitted(ClusterNode.java:614)
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:725)
> at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:162)
> at org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:475)
> at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:177)
> at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339)
> at org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
> at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
> at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
> at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
> at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
> at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
> at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
> at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
> at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
> at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
> at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
> at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
> at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
> at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
> at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
> at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
> at $Proxy24.saveDocument(Unknown Source)
> at pps.jackrabbit.demo.web.bean.JackRabbitTestBean.submit(JackRabbitTestBean.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
> at javax.faces.component.UICommand.broadcast(UICommand.java:383)
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212)
> at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:361)
> at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
> at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
> Caused by: java.sql.SQLException: Can't call commit when autocommit=true
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:914)
> at com.mysql.jdbc.Connection.commit(Connection.java:2273)
> at org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:311)
> ... 67 more
>
> Thanks for your help,
> Dainius
>