Interfacing with Database on Server

[Frederic Bregier]

Hi,

For 1) The execution handler is included in the pipeline at construction
(from a factory for instance) and you don't have to take care of it. Its
goal is "just" to enable a new thread pool to execute the next handlers such
that those handlers do not run in the IO thread. And as you do external
request (like SGBD) which could take long time, then you have the good idea
to include this execution handler.
So on your question, just include it in the pipeline at construction then
forget it.

2) For the initialization of the connection pool, I would suggest to do it
before creating the server bootstrap and to pass this connection pool as a
fix argument to your ChannelPipelineFactory such that any new pipeline will
create the business handler with this pool as argument like :

public class YourPipelinbeFactory implements ChannelPipelineFactory {
private YourPool yourPool;
private OrderedMemoryAwareThreadPoolExecutor yourExec;
public YourPipelineFactory(YourPool yourPool) {
   this.yourPool = yourPool;
   yourExec = new OrderedMemoryAwareThreadPoolExecutor(...);
}
/**
* Returns a newly created {@link ChannelPipeline}.
*/
ChannelPipeline getPipeline() throws Exception;
        ChannelPipeline pipeline = Channels.pipeline();
        pipeline.addLast("codec", new YourCodec());
        pipeline.addLast("Exec", yourExec);
        pipeline.addLast("handler", new YourBusinessHandler(yourPool));
        return pipeline;
}

then in the YourBusinessHandler, you can use the pool to request a new
connection from the pool.

3) No you don't have to make the Handler create a runnable objet. Just
extends SimpleChannelHandler for instance should be enough. As the Executor
handler is before the business handler, you already have the thread support.

So in your businessHandler, you could do something like :

public class YourBusinessHandler extends SimpleChannelHandler {
private YourPool yourPool;
public YourBusinessHandler(YourPool  yourPool) {
   this.yourPool = yourPool
}
public void messageReceived(ChannelHandlerContext ctx,
                            MessageEvent e) {
   // get the message from e
   xxx
   // determine if a request has to be done
   // if so, get a connection from the pool
   // then execute the request
  // determine if a response is needed
  // if so
  ctx.getChannel.write(response);
  // determine if the connection should be closed or not (generaly, the
client close the connection
  // but it depends on the logic of the protocol)
}

}

In fact, you are almost there if I get your point... ;-)

HTH,
Frederic


vimana wrote:
> 
> Hi,
> 
> Thanks for your response. It certainly cleared a number of questions.
> I'm still a bit unsure of the following:
> 1. How does the execution handler interact with the process mentioned
> below?
> I'm guessing I would need to execute the query using the execution
> handler? If so, would I need to pass the query to the execution handler
> using the sendupstream? I'm still confused on how to make use of the
> execution handler. I've looked at the API and I'm still very confused on
> this.
> 
> 2. Where do I create and initialize my connection pool?
> 
> 3. Do I need to create a runnable object in my Business Logic Handler
> class?
> 
> At the moment I'm using my business logic handler to receive the message
> -> check if the message is to write to a database (no response to send to
> client), or to retrieve data from the database (response sent back to
> client as xml). At this point, I was thinking of generating the sql query
> and passing the query string downstream to the DB Handler. The DB Handler
> would retrieve a connection from the connection pool and execute the query
> and the result (if any) would be passed back to the Business Logic
> Handler. The business logic handler will forward it back to the client
> using write(Object) which would invoke the encoder codec. But in this
> process, at which point does the execution handler get invoked? And is
> there a particular method which I must call upon to invoke the execution
> handler from within the DB Handler or Business Logic Handler?
> 
> Thanks!
> 
> 
> 
> Frederic Bregier wrote:
>> 
>> Hi,
>> 
>> I would suggest something in your pipeline like in that order :
>> 
>> - handlers for codec (your protocol on how to receive or answer
>> information)
>> - handler for execution handler (OrderedMemoryAwareThreadPoolExecutor)
>> - handler for business
>> 
>> In your business, you could make all of your business code, including the
>> request from the DB pool.
>> Then you know what and when you need to answer to the client.
>> 
>> Another option is as you wrote:
>> - handlers for codec (your protocol on how to receive or answer
>> information)
>> - handler for execution handler (OrderedMemoryAwareThreadPoolExecutor)
>> - handler for business
>> - handler for DB connection and queries
>> 
>> Then your business just pass the request (if any) to the Db Connection
>> and Queries handler (using downstream).
>> The Db Conn & Query handler if needed to answer just write the answer (in
>> the form you need for instance as an Object) using upstream.
>> Then the business get the upstream and decide or not to forward it to the
>> client...
>> 
>> But my guess is that only one handler is easier but it greatly depends on
>> your dev and logic...
>> 
>> HTH,
>> Frederic
>> 
>> 
>> vimana wrote:
>>> 
>>> Hi,
>>> 
>>> I'm having difficulty understanding how to interface with a DB (MySQL)
>>> on the Server.
>>> From what I've gathered, I'll need to create a connection pool (which
>>> I've done using Apache DBCP), add an execution handler to my pipeline (I
>>> used the OrderedMemoryAwareThreadPoolExecutor) and my business logic
>>> handler checks if the request from the client is to save something to
>>> the db or retrieve something from the db. I then would want the business
>>> logic handler to pass this request to the execution handler which will
>>> grab a connection from the connection pool and run the query. If the
>>> query was to return a result to the client then the execution handler
>>> would write the result back to the client. I'm not sure if this is the
>>> correct way to go about it and if it is how do I pass the request from
>>> the logic handler to execution handler (sendupstream?). And How does the
>>> execution handler receive the message ? Do i attach a runnable object to
>>> the context object associated with the channel in the business logic
>>> handler, sendupstream and then in the handleupstream in Executionhandler
>>> get the attachment and do a .execute((Runnble)ctx.getAttachment())? 
>>> 
>>> It would help a lot if I can get a high level overview of the correct
>>> way to interact with the database.
>>> 
>>> Thanks!
>>> 
>> 
>> 
> 
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/Interfacing-with-Database-on-Server-tp3874876p3881245.html
Sent from the Netty User Group mailing list archive at Nabble.com.