Von: Michael Smith [mailto:[EMAIL PROTECTED]
My point was that the original hack is just that - a hack. It doesn't fix the problem, nor does it completely guarantee that the system will work correctly. The hack _should_ be removed entirely - but to do that, the store must be made capable of correctly dealing with lost connections. I agree completely that the performance implications of that hack are unacceptable - but the solution to THAT is to fix the actual problem, not to patch around the performance problem whilst keeping the underlying (broken) system.
+1 :-) But as far as I know there is no possibilty to check if a JDBC connection is broken without executing an statement.
That's probably true - I think that's why that hack works as it does. The only way to fix this is to make the code able to deal with errors that are due to dropped db connections, and to automatically reconnect/retry. I'd think this is fairly standard and straightforward stuff - though I'm neither a database expert nor a JDBC expert - surely just about anything that uses persistent db connections has to deal with this?
I guess the main problem are the cached data which do not execute an sql-statement. So how should this work?
BTW: is it allowed to modify the content of an database while Slide is
using it? If not, then the hack is obsolete at all, isn't it?
No, you can't modify the database underneath slide (the caches will break). The hack is there because without it, users were seeing (whenever they were accessing a slide instance that hadn't been accessed for N minutes (what N is depends on the database, etc.)) random errors come up because the connection had been dropped. The code can't deal correctly with these errors at the moment. I doubt this would be difficult to fix for someone who actually knows how to use JDBC properly.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
