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.
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.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
