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]
