* JDBCDescriptorsStore configurable connection checking (passed in seconds)
<parameter name="checkinterval">60</parameter>
thus the check-connection statement is not always executed
for compatibility, the default value is 0 and the check
is always performed.
The first three changes sound good - send patches to this mailing list. The last is incorrect - adding an additional hack on top of the connection-checking hack is not an acceptable "fix". That
Nop. It's not another hack, it's a very simple modification of the hack. For me, it's not acceptable that the initial hack consumes about 75% of the overall execution time (yes I am not kidding, simply use a profiler and verify it)! So I simply added an option where the users can fine-tune the store according to their needs. In all my experiences with databases, loosing a connection occured very, very seldomly. Thus it's worth the risk to have your caches for ~30 seconds *maybe* out of sync. But no matter, if you need the full security, then don't modify the checker interval. But other people may have other opinions. Let them choose their own settings if it boosts application performance by factor 2.
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.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
