I'm see in AbstractWebdavMethod that setForceStoreEnlistment is only
being set to true during an external transaction. Is this intentional?
-James
James Mason wrote:
Well, I think I know what's happening now. Here's a stack trace from a
failed GET:
java.lang.Throwable
at
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter.retrieveRevisionContent(StandardRDBMSAdapter.java:726)
at
org.apache.slide.store.impl.rdbms.AbstractRDBMSStore.retrieveRevisionContent(AbstractRDBMSStore.java:734)
at
org.apache.slide.store.AbstractStore.retrieveRevisionContent(AbstractStore.java:1314)
at
org.apache.slide.store.ExtendedStore.retrieveRevisionContent(ExtendedStore.java:492)
at org.apache.slide.content.ContentImpl.retrieve(ContentImpl.java:352)
at org.apache.slide.content.ContentImpl.retrieve(ContentImpl.java:322)
at
org.apache.slide.webdav.method.GetMethod.executeRequest(GetMethod.java:218)
If you compare line numbers with the code you'll notice that this
request is happening outside of a transaction. Line 1287 in
AbstractStore (isForceStoreEnlistment(uri)) is returning false. What
ends up happening is all the classes assume someone else will end up
closing the connection, and it never gets closed. If I set the max pool
size to 1 GetMethod never returns.
I'll look into why SlideToken doesn't think it's part of a transaction,
but I figured you might be able to find it faster :).
-James
Oliver Zeigermann wrote:
James Mason wrote:
More below.
Oliver Zeigermann wrote:
Another thing you may want to try. In
org.apache.slide.store.impl.rdbms.AbstractRDBMSStore when there is a
read only request outside of a transaction a new connection is
retrieved from the pool, the request is done and the connection
closed. Maybe MySQL needs a commit or rollback before the connection
close? Maybe it starts a transaction even with a read request? I do
not know. To be on the save side try to add it and do it quick replace:
connection.close();
with
connection.commit();
connection.close();
But leave sequence methods as they are.
I modified retrieveObject() in AbstractRDBMSStore. Is this the method
you meant? I haven't noticed any change in behavior.
Try this modification with *all* connection.close() statements in
AbstractRDBMSStore, except the ones for sequences.
Oliver
Oliver Zeigermann wrote:
All this is in one transaction? Only a single client? Then a *real*
deadlock is indeed unlikely.
There is a pre-check outside of the real transaction to see if the
resource you request is a collection. If so a HTML page will be
generated. Maybe this is the source of the problem. To check,
please comment out that check and see if it works. The check is
done in org.apache.slide.webdav.WebdavServlet in line 153 with
isCollection(req). Try replacing it with false for the test.
Tried this too. Didn't help.
Do not mean to let you down, but this was my last idea. Isn't there
anyone out there experiencing the same? You can't be the only one
using MySQL...
I'm going to try to figure out when/where the second connection is
getting opened. Let me know if you think of anything else I could try.
Please tell if there is anything I can do to help you with this.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
