Don't do it
It's best not to directly access the database in an IChannel. Re-architect so that your IChannel accesses service implementations which in turn are backed by DAOs. Including actual database connection and SQL query code in the IChannel class itself leads to long and complicated IChannel implementations. Adding some abstraction allows you to think of this in terms of what services your IChannel needs to consume and expose, and then elsewhere, in service implementations and DAOs, you can place the code that makes those services real.
What is your IChannel doing? Is it something that would be of interest to other uPortal deployers? If there's enough interest, potentially by factoring this such that there's a pluggable DAO layer, you can share this channel with others and their work in getting it deployable in their environment is to reconfigure or re-implement the DAOs to point at their data.
A layered architecture buys a lot, even in IChannels.
Getting at the Database
uPortal's IChannel API is very good at configurably provisioning IChannel instances with String configuration parameters, which can be specified at channel publish and/or subscribe time and are mediated by a declaratively configurable channel publishing workflow (CPDs). uPortal is much less elegant at injecting into channels the non-String resources they need.
...