You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <ol...@zeigermann.de> on 2004/08/02 09:08:36 UTC
Re: More on deadlocks
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: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
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: slide-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Andreas Probst <an...@gmx.net>.
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: slide-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
This should be done with my latest commit. Could anyone check if I have
got them all?
Thanks,
Oliver
Oliver Zeigermann wrote:
> Hmmm, thinking about it. I should really call commit on temporary
> connections before closing to be on the save side...
>
> Oliver
>
> Oliver Zeigermann wrote:
>
>> So, you implemented your own connection pool? Cool stuff... If it
>> works what should be the problem.
>>
>> I just checked DBCP the default connection pool for Slide and it
>> actually seems connections do not get committed or rolled back before
>> they are returned to the pool. However, I understand that no new
>> transaction is started on a connection when there is no write request
>> in it, right?
>>
>> Oliver
>>
>> Andreas Probst wrote:
>>
>>> on 2 Aug 2004 at 17:30, Oliver Zeigermann 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.
>>>>
>>>>
>>>>
>>>> Not quite sure what your intention is here. Could you please clarify?
>>>>
>>>
>>>
>>> For our project I'm bound to a Slide head version of late November
>>> 2003, where there wasn't a database connection pool yet. I think now
>>> there is one somehow.
>>> Within a few minutes there were hundreds of connections opened and
>>> closed. This works for MS SQL Server on a Windows Server machine.
>>> However, on Windows XP the closed connections were not freed fast
>>> enough. So I got NoFreeSocket or so inside the SQLException. With
>>> Oracle opening and closing connections all the time would not work at
>>> all, no matter which OS. (This is what our database expert says.)
>>> That's why I implemented a database connection pool. A call to
>>> getConnection() or getNewConnection() or so in AbstractDBMSStore or
>>> so (I don't know the names by heart and now I'm on vacation ;)
>>> returns a connection from the pool of connections. The connections
>>> are bound to the current thread. Within a single thread the same
>>> connection is returned. Within another thread another connection is
>>> returned. When close() is called on the connection wrapper object, it
>>> is not really closed but put back to the pool of connections.
>>>
>>> With this pool I have a fixed number of connection during the whole
>>> runtime of the server. In my tests I archived more than 1 million
>>> documents in one run. So this works.
>>>
>>> As there is always the same connection returned within the same
>>> thread, all statements live within the transaction, which was started
>>> in the WebDAV layer. Even if the stores are not enlisted in the
>>> transaction, they really are, because they work on the same database
>>> connection.
>>>
>>> I hope this does not cause any problems. So far it works fine for the
>>> plain WebDAV operations.
>>>
>>> I hope this explains what I meant...
>>>
>>> Andreas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Hmmm, thinking about it. I should really call commit on temporary
connections before closing to be on the save side...
Oliver
Oliver Zeigermann wrote:
> So, you implemented your own connection pool? Cool stuff... If it works
> what should be the problem.
>
> I just checked DBCP the default connection pool for Slide and it
> actually seems connections do not get committed or rolled back before
> they are returned to the pool. However, I understand that no new
> transaction is started on a connection when there is no write request in
> it, right?
>
> Oliver
>
> Andreas Probst wrote:
>
>> on 2 Aug 2004 at 17:30, Oliver Zeigermann 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.
>>>
>>>
>>> Not quite sure what your intention is here. Could you please clarify?
>>>
>>
>>
>> For our project I'm bound to a Slide head version of late November
>> 2003, where there wasn't a database connection pool yet. I think now
>> there is one somehow.
>> Within a few minutes there were hundreds of connections opened and
>> closed. This works for MS SQL Server on a Windows Server machine.
>> However, on Windows XP the closed connections were not freed fast
>> enough. So I got NoFreeSocket or so inside the SQLException. With
>> Oracle opening and closing connections all the time would not work at
>> all, no matter which OS. (This is what our database expert says.)
>> That's why I implemented a database connection pool. A call to
>> getConnection() or getNewConnection() or so in AbstractDBMSStore or so
>> (I don't know the names by heart and now I'm on vacation ;) returns a
>> connection from the pool of connections. The connections are bound to
>> the current thread. Within a single thread the same connection is
>> returned. Within another thread another connection is returned. When
>> close() is called on the connection wrapper object, it is not really
>> closed but put back to the pool of connections.
>>
>> With this pool I have a fixed number of connection during the whole
>> runtime of the server. In my tests I archived more than 1 million
>> documents in one run. So this works.
>>
>> As there is always the same connection returned within the same
>> thread, all statements live within the transaction, which was started
>> in the WebDAV layer. Even if the stores are not enlisted in the
>> transaction, they really are, because they work on the same database
>> connection.
>>
>> I hope this does not cause any problems. So far it works fine for the
>> plain WebDAV operations.
>>
>> I hope this explains what I meant...
>>
>> Andreas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
So, you implemented your own connection pool? Cool stuff... If it works
what should be the problem.
I just checked DBCP the default connection pool for Slide and it
actually seems connections do not get committed or rolled back before
they are returned to the pool. However, I understand that no new
transaction is started on a connection when there is no write request in
it, right?
Oliver
Andreas Probst wrote:
> on 2 Aug 2004 at 17:30, Oliver Zeigermann 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.
>>
>>Not quite sure what your intention is here. Could you please clarify?
>>
>
>
> For our project I'm bound to a Slide head version of late
> November 2003, where there wasn't a database connection pool
> yet. I think now there is one somehow.
>
> Within a few minutes there were hundreds of connections opened
> and closed. This works for MS SQL Server on a Windows Server
> machine. However, on Windows XP the closed connections were not
> freed fast enough. So I got NoFreeSocket or so inside the
> SQLException. With Oracle opening and closing connections all
> the time would not work at all, no matter which OS. (This is
> what our database expert says.)
>
> That's why I implemented a database connection pool. A call to
> getConnection() or getNewConnection() or so in AbstractDBMSStore
> or so (I don't know the names by heart and now I'm on vacation
> ;) returns a connection from the pool of connections. The
> connections are bound to the current thread. Within a single
> thread the same connection is returned. Within another thread
> another connection is returned. When close() is called on the
> connection wrapper object, it is not really closed but put back
> to the pool of connections.
>
> With this pool I have a fixed number of connection during the
> whole runtime of the server. In my tests I archived more than 1
> million documents in one run. So this works.
>
> As there is always the same connection returned within the same
> thread, all statements live within the transaction, which was
> started in the WebDAV layer. Even if the stores are not enlisted
> in the transaction, they really are, because they work on the
> same database connection.
>
> I hope this does not cause any problems. So far it works fine
> for the plain WebDAV operations.
>
> I hope this explains what I meant...
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Andreas Probst <an...@gmx.net>.
on 2 Aug 2004 at 17:30, Oliver Zeigermann 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.
>
> Not quite sure what your intention is here. Could you please clarify?
>
For our project I'm bound to a Slide head version of late
November 2003, where there wasn't a database connection pool
yet. I think now there is one somehow.
Within a few minutes there were hundreds of connections opened
and closed. This works for MS SQL Server on a Windows Server
machine. However, on Windows XP the closed connections were not
freed fast enough. So I got NoFreeSocket or so inside the
SQLException. With Oracle opening and closing connections all
the time would not work at all, no matter which OS. (This is
what our database expert says.)
That's why I implemented a database connection pool. A call to
getConnection() or getNewConnection() or so in AbstractDBMSStore
or so (I don't know the names by heart and now I'm on vacation
;) returns a connection from the pool of connections. The
connections are bound to the current thread. Within a single
thread the same connection is returned. Within another thread
another connection is returned. When close() is called on the
connection wrapper object, it is not really closed but put back
to the pool of connections.
With this pool I have a fixed number of connection during the
whole runtime of the server. In my tests I archived more than 1
million documents in one run. So this works.
As there is always the same connection returned within the same
thread, all statements live within the transaction, which was
started in the WebDAV layer. Even if the stores are not enlisted
in the transaction, they really are, because they work on the
same database connection.
I hope this does not cause any problems. So far it works fine
for the plain WebDAV operations.
I hope this explains what I meant...
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Andreas Probst wrote:
> 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.
Not quite sure what your intention is here. Could you please clarify?
Thanks,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Andreas Probst <an...@gmx.net>.
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: slide-dev-unsubscribe@jakarta.apache.org
> >>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
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? 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: slide-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: More on deadlocks
Posted by James Mason <ma...@apache.org>.
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 :).
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.
-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: slide-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org