2

In order to efficiently use connection pooling via BoneCP while programming a Netty server- where is the correct place for the connection pool and where to get a new connection for that pool?

At a glance- I'm thinking that BoneCP should be some sort of global/singleton initialized just once in the main server, and then each handler (i.e. the class passed as "handler" to the pipeline) references that singleton to grab a new connection... but I don't see any examples of that on the net and, being new to Java, I'm a little concerned to jump right in with that approach. Would be great to hear an experienced voice!

davidkomer
  • 3,020
  • 2
  • 23
  • 58

2 Answers2

1

Yes, a channel handler can very well use the BoneCP connection pool, but you should definitively insert an ExecutionHandler in front of the BoneCP handler. You do not want to issue blocking db calls in a netty IO worker thread.

forty-two
  • 12,204
  • 2
  • 26
  • 36
  • Is this also necessary with netty 4.0? My particular use-case is that certain commands will go through the getConnection(), executeStatement(), close() process- but others won't. Would be a lot easier to read if I can keep all that in the same class :) – davidkomer Oct 25 '12 at 11:57
  • The principle must be the same with netty 4 (I don't know the specifics, however). Never perform blocking operations on the IO worker threads – forty-two Oct 25 '12 at 12:50
  • I'm a bit confused then- where do I maintain the private vars and things like that? My use-case is that a client will connect, and remain connected for a long period of time while the unique status (and other vars) is remembered serverside for that connection for the duration of use – davidkomer Oct 25 '12 at 12:58
0

There's also this defined in bonecp:

public ListenableFuture getAsyncConnection(){

    return this.asyncExecutor.submit(new Callable<Connection>() {

        public Connection call() throws Exception {
            return getConnection();
        }});
}
wwadge
  • 3,506
  • 1
  • 19
  • 28