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 Alexander Demidovich <a_...@yahoo.com> on 2001/06/25 13:10:32 UTC
Database connection lost
Hi
Has been Slide tested for cases when the database connection
was dropped unexpectedly? For example, database crash...
I've tried and it looks not so good. I mean, I had to restart
the Tomcat
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Database connection lost
Posted by Jason Harrop <ja...@xn.com.au>.
> Ok, so it's indeed broken. The thing is that there's no way to know if the
> JDBC exception you get indicates that the connection is broken, that the SQL
> is bad, or something else :-(
That's right. So the way i wrote the patch, i assume the connection is
broken (and don't try to close it), create a new one, and try
connection.prepareStatement again. If the connection was indeed broken,
then with a bit of luck, we'll now have a valid one, and
connection.prepareStatement won't throw an exception. If the SQL is bad
or something else is the problem, well this time around, the exception
thrown by connection.prepareStatement will get handled by the existing
code.
cheers,
Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Database connection lost
Posted by "Nicholas S. Barratt" <ni...@mindcruiser.com>.
Hi all -
Connections should really have an isValid() method, eh?
> Ok, so it's indeed broken. The thing is that there's no way to know if
the
> JDBC exception you get indicates that the connection is broken,
> that the SQL is bad, or something else :-(
In my company's software, a connection is checked every Xth time it is
released to the connection pool by performing some sort of NOOP, like
"select 1 from dual" in the case of Oracle. If this throws an exception,
then we mark the connection as down. An improved heuristic would then
mark all other connections in the pool for immediate checking.
I don't know if that would work in your context, but good luck!
Re: Database connection lost
Posted by Remy Maucherat <re...@apache.org>.
> Slide's connectIfNeeded method didn't work, so i did check. Here is
> what the spec says at
>
http://java.sun.com/products/jdk/1.2/docs/guide/jdbc/spec2/jdbc2.0.frame11.h
tml
>
> "11 Clarifications
> We have gotten several requests to clarify some aspects of the JDBC API.
> This chapter contains additional explanation of some JDBC features.
>
> 11.1 Connection.isClosed()
> The Connection.isClosed() method is only guaranteed to return true after
> Connection.closed() has been called. Connection.isClosed() cannot be
> called, in general, to determine if a database connection is valid or
> invalid. A typical JDBC client can determine that a connection is
> invalid by catching the exception that is thrown when a JDBC operation
> is attempted."
>
> This also affects the semantics of our isConnected() method.
Ok, so it's indeed broken. The thing is that there's no way to know if the
JDBC exception you get indicates that the connection is broken, that the SQL
is bad, or something else :-(
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Jason Harrop <ja...@xn.com.au>.
Slide's connectIfNeeded method didn't work, so i did check. Here is
what the spec says at
http://java.sun.com/products/jdk/1.2/docs/guide/jdbc/spec2/jdbc2.0.frame11.html
"11 Clarifications
We have gotten several requests to clarify some aspects of the JDBC API.
This chapter contains additional explanation of some JDBC features.
11.1 Connection.isClosed()
The Connection.isClosed() method is only guaranteed to return true after
Connection.closed() has been called. Connection.isClosed() cannot be
called, in general, to determine if a database connection is valid or
invalid. A typical JDBC client can determine that a connection is
invalid by catching the exception that is thrown when a JDBC operation
is attempted."
This also affects the semantics of our isConnected() method.
cheers,
Jason
Remy Maucherat wrote:
>>Hi
>>
>>Currently with the JDBCDescriptorsStore, when the database connection is
>>unexpectedly lost, we have to restart Tomcat to recreate the connection.
>>
>>I've attached a stack trace which shows the problem.
>>
>>I thought it looked easy enough to solve - just add connectIfNeeded()
>>before each attempt to use the connection (catching
>>ServiceConnectionFailedException).
>>
>>But isClosed() as used in that method can't actually determine whether
>>the connection is invalid, so instead, i try to connect if
>>connection.prepareStatement throws an SLQException.
>>
>>Patch is attached.
>>
>
> Maybe, but shouldn't isClosed return the actual status of the connection ?
> If the spec says it should, then I don't think we should add some other
> workarounds in the code.
>
> Remy
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Remy Maucherat <re...@apache.org>.
> Hi
>
> Currently with the JDBCDescriptorsStore, when the database connection is
> unexpectedly lost, we have to restart Tomcat to recreate the connection.
>
> I've attached a stack trace which shows the problem.
>
> I thought it looked easy enough to solve - just add connectIfNeeded()
> before each attempt to use the connection (catching
> ServiceConnectionFailedException).
>
> But isClosed() as used in that method can't actually determine whether
> the connection is invalid, so instead, i try to connect if
> connection.prepareStatement throws an SLQException.
>
> Patch is attached.
Maybe, but shouldn't isClosed return the actual status of the connection ?
If the spec says it should, then I don't think we should add some other
workarounds in the code.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Colin Britton <cb...@metatomix.com>.
Actually , I dont think we can merge them back as one since one abstracts
abstractSimpleService and the other abstractService. So at least a helper
classs for the sql methods then.
We should put the sql (and common code) from both the descriptors and
content versons of the stores in the same helper.
rgds
CB
----- Original Message -----
From: "Colin Britton" <cb...@metatomix.com>
To: "Slide Developers List" <sl...@jakarta.apache.org>
Sent: Saturday, January 12, 2002 2:53 PM
Subject: Re: Database connection lost
> > We should also think about merging the sql code from JDBC and J2EE
> > stores.
> >
>
> We could merge them back as one store and use a configuration parameter
> (such as if datasource parameter exists) as the key as to which type of
> store it is. If you agree I will get this going.
>
> rgds
> CB
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Colin Britton <cb...@metatomix.com>.
> We should also think about merging the sql code from JDBC and J2EE
> stores.
>
We could merge them back as one store and use a configuration parameter
(such as if datasource parameter exists) as the key as to which type of
store it is. If you agree I will get this going.
rgds
CB
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Dirk Verbeeck <di...@pandora.be>.
Just had a look at WebdavMethod::methodNeedsTransactionSupport and it
seems all webdav methods have transactionsupport turned on.
Do you know if a Connection object is thread-safe?
I thought it is not but I can't find any info on it.
Dirk
Jason Harrop wrote:
>
> Hello Dirk
>
> Thanks for looking at my patch and explaining its deficiencies.
>
> > There are other optimalizations (retry is possible on read-only methods
> > outside a transaction)
>
> Currently the read-only methods also occur inside a transaction, correct?
>
> I'm still finding it easy to crash slide using the JDBCDescriptorsStore,
> if one person is doing a write while another is trying to do a read or
> a write.
>
> At the beginning of November, in relation to bug 3935, Remy said:
>
> > Given the description, it really looks to me like a race condition.
> > At this point, I think we should try to sync everything transaction
> related
> > and see what happens.
> > Could you try and add a synchronized keyword to all the methods in
> > AbstractSimpleService and try again ?
> > It probably would be worth trying to sync the transaction manager methods
> > too.
> >
> > The transaction itself doesn't need to be synced, since there's a 1-1
> > mapping between the transaction object and the thread.
> >
>
> I'm pretty sure our copy of AbstractSimpleService (but not
> SlideTransactionManager) has had the synchronized keyword in all the
> methods since then, but it still crashes.
>
> Which is why i'm keen to use the J2EEDescriptorsStore, if it can be made
> to work with SlideRealm. I guess i also need to see what happens with
> the J2EEDescriptorsStore if the connection is lost..;)
>
> > but these can wait until we know the results of this modification.
>
> i shall do some testing.
>
> thanks
>
> Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Jason Harrop <ja...@xn.com.au>.
Hello Dirk
Thanks for looking at my patch and explaining its deficiencies.
> There are other optimalizations (retry is possible on read-only methods
> outside a transaction)
Currently the read-only methods also occur inside a transaction, correct?
I'm still finding it easy to crash slide using the JDBCDescriptorsStore,
if one person is doing a write while another is trying to do a read or
a write.
At the beginning of November, in relation to bug 3935, Remy said:
> Given the description, it really looks to me like a race condition.
> At this point, I think we should try to sync everything transaction
related
> and see what happens.
> Could you try and add a synchronized keyword to all the methods in
> AbstractSimpleService and try again ?
> It probably would be worth trying to sync the transaction manager methods
> too.
>
> The transaction itself doesn't need to be synced, since there's a 1-1
> mapping between the transaction object and the thread.
>
I'm pretty sure our copy of AbstractSimpleService (but not
SlideTransactionManager) has had the synchronized keyword in all the
methods since then, but it still crashes.
Which is why i'm keen to use the J2EEDescriptorsStore, if it can be made
to work with SlideRealm. I guess i also need to see what happens with
the J2EEDescriptorsStore if the connection is lost..;)
> but these can wait until we know the results of this modification.
i shall do some testing.
thanks
Jason
> We should also think about merging the sql code from JDBC and J2EE
> stores.
>
> Dirk
>
> Jason Harrop wrote:
>
>>Hi
>>
>>Currently with the JDBCDescriptorsStore, when the database connection is
>>unexpectedly lost, we have to restart Tomcat to recreate the connection.
>>
>>I've attached a stack trace which shows the problem.
>>
>>I thought it looked easy enough to solve - just add connectIfNeeded()
>>before each attempt to use the connection (catching
>>ServiceConnectionFailedException).
>>
>>But isClosed() as used in that method can't actually determine whether
>>the connection is invalid, so instead, i try to connect if
>>connection.prepareStatement throws an SLQException.
>>
>>Patch is attached.
>>
>>cheers,
>>
>>Jason
>>
>>6 months ago, Alexander Demidovich wrote:
>>
>>
>>>>Hi
>>>>
>>>>Has been Slide tested for cases when the database connection
>>>>was dropped unexpectedly? For example, database crash...
>>>>
>>>>I've tried and it looks not so good. I mean, I had to restart
>>>>the Tomcat
>>>>
>>>>
>>Remy Maucherat wrote:
>>
>>>Well, if there is a problem with that, it should be easy to fix, since there
>>>is a lot of code in there to handle that situation.
>>>Looking at the code, I think a reconnect should happen in all cases (but, of
>>>course, I could have missed something).
>>>
>>>Can you translate "it looks not so good" into a stack trace (if you got one)
>>>?
>>>
>>>One problem that could be fixed is that Uri.parseUri (which will be called
>>>if there are some connection problems) swallows exceptions. I think I'll add
>>>some logging there.
>>>
>>>Remy
>>>
>>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi
Jason, I can't apply your patch, there is a problem with transactions.
When you are inside a method at this low level you cannot know is there
were already
updates done before the connection was closed, that's why you cannot
reconnect and continue. The ServiceAccessException must be thrown. The
only place where you could implement a retry is on on a high level where
you know about the transactional state.
On servlet/method level we could implement a retry but then again the
following might be enough:
connectIfNeeded() can be called when there is an error, reconnecting for
the next request.
The remarks from Nicholas also makes sense.
- isConnected() will include a test with a NOOP statement. "select 1
from aTable"
- test the connection when a new transaction starts
There are other optimalizations (retry is possible on read-only methods
outside a transaction)
but these can wait until we know the results of this modification.
We should also think about merging the sql code from JDBC and J2EE
stores.
Dirk
Jason Harrop wrote:
>
> Hi
>
> Currently with the JDBCDescriptorsStore, when the database connection is
> unexpectedly lost, we have to restart Tomcat to recreate the connection.
>
> I've attached a stack trace which shows the problem.
>
> I thought it looked easy enough to solve - just add connectIfNeeded()
> before each attempt to use the connection (catching
> ServiceConnectionFailedException).
>
> But isClosed() as used in that method can't actually determine whether
> the connection is invalid, so instead, i try to connect if
> connection.prepareStatement throws an SLQException.
>
> Patch is attached.
>
> cheers,
>
> Jason
>
> 6 months ago, Alexander Demidovich wrote:
>
> >>Hi
> >>
> >>Has been Slide tested for cases when the database connection
> >>was dropped unexpectedly? For example, database crash...
> >>
> >>I've tried and it looks not so good. I mean, I had to restart
> >>the Tomcat
> >>
>
> Remy Maucherat wrote:
> > Well, if there is a problem with that, it should be easy to fix, since there
> > is a lot of code in there to handle that situation.
> > Looking at the code, I think a reconnect should happen in all cases (but, of
> > course, I could have missed something).
> >
> > Can you translate "it looks not so good" into a stack trace (if you got one)
> > ?
> >
> > One problem that could be fixed is that Uri.parseUri (which will be called
> > if there are some connection problems) swallows exceptions. I think I'll add
> > some logging there.
> >
> > Remy
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connection lost
Posted by Jason Harrop <ja...@xn.com.au>.
Hi
Currently with the JDBCDescriptorsStore, when the database connection is
unexpectedly lost, we have to restart Tomcat to recreate the connection.
I've attached a stack trace which shows the problem.
I thought it looked easy enough to solve - just add connectIfNeeded()
before each attempt to use the connection (catching
ServiceConnectionFailedException).
But isClosed() as used in that method can't actually determine whether
the connection is invalid, so instead, i try to connect if
connection.prepareStatement throws an SLQException.
Patch is attached.
cheers,
Jason
6 months ago, Alexander Demidovich wrote:
>>Hi
>>
>>Has been Slide tested for cases when the database connection
>>was dropped unexpectedly? For example, database crash...
>>
>>I've tried and it looks not so good. I mean, I had to restart
>>the Tomcat
>>
Remy Maucherat wrote:
> Well, if there is a problem with that, it should be easy to fix, since there
> is a lot of code in there to handle that situation.
> Looking at the code, I think a reconnect should happen in all cases (but, of
> course, I could have missed something).
>
> Can you translate "it looks not so good" into a stack trace (if you got one)
> ?
>
> One problem that could be fixed is that Uri.parseUri (which will be called
> if there are some connection problems) swallows exceptions. I think I'll add
> some logging there.
>
> Remy
>
>
>
>
07 Jan 2002 13:17:22 - slidestore.reference.JDBCDescriptorsStore - ERROR
- java.sql.SQLException: Io exception: Connection reset by peer: socket
write error
java.sql.SQLException: Io exception: Connection reset by peer: socket
write error
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:210)
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:323)
at oracle.jdbc.driver.OracleStatement.<init>(OracleStatement.java:417)
at oracle.jdbc.driver.OracleStatement.<init>(OracleStatement.java:432)
at
oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:182)
at
oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:165)
at
oracle.jdbc.driver.OracleConnection.privatePrepareStatement(OracleConnection.java:604)
at
oracle.jdbc.driver.OracleConnection.prepareStatement(OracleConnection.java:485)
at
slidestore.reference.JDBCDescriptorsStore.retrieveObject(JDBCDescriptorsStore.java:570)
at
org.apache.slide.store.StandardStore.retrieveObject(StandardStore.java:171)
at org.apache.slide.security.SecurityImpl.getPrincipal(SecurityImpl.java:765)
at wrappers.catalina.SlideRealm.getPassword(SlideRealm.java:255)
at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:314)
at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:163)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1006)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1100)
at java.lang.Thread.run(Thread.java:484)
07 Jan 2002 13:17:22 - org.apache.slide.common.Domain - WARNING -
Service slidestore.reference.JDBCDescriptorsStore@5f280b access error :
Io exception: Connection reset by peer: socket write error
Re: Database connection lost
Posted by Remy Maucherat <re...@apache.org>.
> Hi
>
> Has been Slide tested for cases when the database connection
> was dropped unexpectedly? For example, database crash...
>
> I've tried and it looks not so good. I mean, I had to restart
> the Tomcat
Well, if there is a problem with that, it should be easy to fix, since there
is a lot of code in there to handle that situation.
Looking at the code, I think a reconnect should happen in all cases (but, of
course, I could have missed something).
Can you translate "it looks not so good" into a stack trace (if you got one)
?
One problem that could be fixed is that Uri.parseUri (which will be called
if there are some connection problems) swallows exceptions. I think I'll add
some logging there.
Remy