Not quite sure, I still think it would, as the stores will dynamically
join the transaction, right? Maybe I am missing something here...
Oliver
Andreas Probst wrote:
Hi Oliver,
for me it sounds reasonable to execute all statements inside the
transactions. I think this would also clear the source code as
enlisting and delisting of stores wouldn't be necessary any
more, would it?
Regards,
Andreas
On 2 Aug 2004 at 9:08, 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
