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.
Oliver
James Mason wrote:
Bad news :(.
1) With the isolation level set to serializable the database returns an error after a certain timeout period. I tried setting the isolation level to read_committed, but the database never returned anything and slide appeared to freeze. I'll try again in the morning with logging turned on to see what's actually happening.
2) I have and it is. The logs I posted are with sequential-mode set to "full". I can try setting it to "write", but from your earlier post I got the impression full had a higher level of isolation.
Would connection 3 keep trying to commit and succeed after connection 4 gives up? I notice that connection 4 does rollback and set autocommit (although doesn't issue a commit), but connection 3 never finishes.
Also, I'm using WebFolders as the client here. It issues two requests when uploading a file, a HEAD and then a PUT. For some reason Slide is trying to retrieve the contents from the database in response to the HEAD request, even though the file doesn't exist yet.
I'm also curious what could be causing Slide to open a second connection to attempt the write to the database. Only one client is talking to Slide, so I would think all the requests would be part of the same transaction/connection.
-James
Oliver Zeigermann wrote:
What you describe and what the trace shows looks like the classical deadlock scenario to me.
You observed Connection 3 can not commit, which is because it is dead locked by Connection 4. And the other way round.
If I am correct with the above analysis there are two ways to get this fixed:
(1) Set isolation level to "READ_COMMITTED" or
(2) Update to the latest version from CVS and take over the setting for <parameter name="sequential-mode">full</parameter> from Domain.xml
With MySQL I would recommend (1) as (2) is the "if everything else fails" solution.
Oliver
James Mason wrote:
A description of the behavior I'm seeing can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg11007.html. I haven't tracked down the source of this problem yet, but I have some more information and I'm hoping something will jump out at someone more familiar with the code.
Here are two snips from MySQL's general log file. The first is a failed PUT of a single file using a CVS checkout from the beginning of the week. The second is a successful PUT of the same file using 2.1M1. I don't think the versions are significant, I just couldn't get my checkout install to start working again after I broke it ;).
---------------- failed -------------------
3 Query SELECT 1 FROM VERSION_HISTORY vh, URI u WHERE vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and REVISION_NO = '1.0'
3 Query commit
3 Query rollback
3 Query SET autocommit=1
3 Query SET autocommit=0
3 Query SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
3 Query select vc.CONTENT from VERSION_CONTENT vc, VERSION_HISTORY vh, URI u where vc.VERSION_ID = vh.VERSION_ID and vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and vh.REVISION_NO = '1.0'
4 Connect [EMAIL PROTECTED] on slide
4 Init DB slide
4 Query select round('inf'), round('-inf'), round('nan')
4 Query SHOW VARIABLES
4 Query SET autocommit=1
4 Query SET autocommit=0
4 Query SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
4 Query select 1 from VERSION_CONTENT vc, VERSION_HISTORY vh, URI u where vc.VERSION_ID = vh.VERSION_ID and vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and vh.REVISION_NO = '1.0'
4 Query delete VERSION_CONTENT from VERSION_CONTENT vc, VERSION_HISTORY vh, URI u where vc.VERSION_ID = vh.VERSION_ID and vh.REVISION_NO = '1.0' and vh.URI_ID=u.URI_ID AND u.URI_STRING='/files/2nd Floor.jpg'
4 Query rollback
4 Query rollback
4 Query SET autocommit=1
---------------- successful -------------------
3 Query SELECT 1 FROM VERSION_HISTORY vh, URI u WHERE vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and REVISION_NO = '1.0'
3 Query commit
3 Query rollback
3 Query SET autocommit=1
3 Query SET autocommit=0
3 Query SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
3 Query select 1 from VERSION_CONTENT vc, VERSION_HISTORY vh, URI u where vc.VERSION_ID = vh.VERSION_ID and vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and vh.REVISION_NO = '1.0'
3 Query delete VERSION_CONTENT from VERSION_CONTENT vc, VERSION_HISTORY vh, URI u where vc.VERSION_ID = vh.VERSION_ID and vh.REVISION_NO = '1.0' and vh.URI_ID=u.URI_ID AND u.URI_STRING='/files/2nd Floor.jpg'
3 Query select 1 from VERSION v, URI u where v.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg'
3 Query select 1 from VERSION_HISTORY vh, URI u where vh.URI_ID = u.URI_ID and u.URI_STRING = '/files/2nd Floor.jpg' and REVISION_NO = '1.0'
3 Query insert into VERSION_CONTENT (VERSION_ID, CONTENT) select vh.VERSION_ID, '[... some binary junk ...]’
----------- end logs --------------
Right off I'm seeing that the failed operation opens a second connection (the first column is the connection number) to the database to store the content *without* committing the first transaction. I'm pretty sure this is the cause of the deadlock.
The other odd behavior is that the failed PUT calls retrieveRevisionContent just before it opens the second connection to store the content. This is strange, because the file being uploaded doesn't exist, so there's nothing in the database to retrieve. I've also noticed in Slide's logs that on PUTs where a deadlock occurs GetMethod throws an IllegalStateException while trying to set the size of the response buffer (see the linked to message above).
-James
--------------------------------------------------------------------- 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]
