Please read between the lines: On 2 Aug 2004 at 9:46, Oliver Zeigermann wrote:
> James Mason wrote: > > > I think a vote would be good. Since with the RDBMS stores a read request > > can lock the database it should probably happen in a transaction. I'm > > still learning the intricacies of transactions, though, so don't take my > > word on it :). > > Not quite sure what you mean here. If the read request is not part of a > transaction the locks will only be there for the duration of this single > read statement, not for the duration of the whole transaction. This is > better, isn't is? With implicit transactions there will be database transactions started automatically. These will last until the Connection.close(). Actually one should avoid closing connections. With a connection pool a connection will never be closed so the transaction will last until a commit or rollback. > However, the drawback is things may change between two > reads inside one and the same GET request, which *might* lead to > inconsistent data. This is another pro to have GET start its own > transaction. > > > 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. > > This generally makes sense, but I suspect you want to remove the symptom > of the problem you discovered, not the real cause ;) > > Oliver > > > -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] > > > > > --------------------------------------------------------------------- > 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]
