Bug 118632
| Summary: | PooledConnectionSource.test() does not work for SQL Server | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Web Application Framework | Reporter: | Brett Prucha <pruchaba_bah> |
| Component: | other | Assignee: | ccm-bugs-list |
| Status: | CLOSED EOL | QA Contact: | Jon Orris <jorris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | nightly | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-27 16:52:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The reason I didn't use that test is that postgres doesn't have a dual table so we'd actually have to use a different SQL string depending on the database. I was hoping the getTables() call would be a clever way to avoid doing that, but I guess not. SQL Server doesn't have a dual table either. In the oracle-compatibility.sql file I added this line: -- The equivalent of oracle's dual table. create view dual as select 1 as dummy; It works great. I think I even got that idea from an old nightly build where postgresql's oracle-compatibility.sql had that line in it. I'm not sure what happened to it. Yep I just checked. ccm-core-5.3.0.AUTO.08.11.2003 as that line in it. That dual view is still there in postgresql. You should be able to use that test no problem. |
Description of problem: The comment says: // This should guarantee a db roundtrip on any normal JDBC // implementation. Well I guess SQL Server is not a "normal" JDBC implementation because the test does not work. When the db goes down, no exception is thrown when the current test is run. I changed the test to the following: PreparedStatement ps; ps = conn.prepareStatement("select 1 from dual"); ps.execute(); ps.close(); This can throw a "Connection reset by peer: socket write error" exception where as the previous implementation would not. BTW the current PooledConnectionSource is much better than previous implementations. Thanks!