As for the error, how do you feel about retrieveRevisionContent() in StandardRDBMSAdapter calling NodeRevisionContent.setContent() with a zero length byte array when the content length is equal to zero? This would save a little time, since a database query would be unnecessary, and it would allow the connection to be closed immediately.
-James
Oliver Zeigermann wrote:
Referring to GET this is correct and intentional. The original idea was that there is no need to have a pure read request inside of a transaction. However, this design has been made up before I joined the Slide community and I no longer feel it makes any sense. I would opt for having all requests inside of transactions. I remember there was an issue with automatic user creation which failed in a read request, as it was not part of a transaction.
Would do you people think? Shall we have all methods executed inside of transactions? Shall I start a vote?
Oliver
James Mason wrote:
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]
--------------------------------------------------------------------- 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]
