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