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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
