Interfacing with Database on Server
Trustin Lee (이희승)
trustin at gmail.com
Mon Oct 26 20:58:15 EDT 2009
Just a side note - if you use MySQL server as a backend, you might
want to try adbcj - http://code.google.com/p/adbcj/
It's in the early stage but you might be able to get the most of
asynchronous programming. Let me CC the author of the project just in
case he has something more to add.
HTH
— Trustin Lee, http://gleamynode.net/
On Sun, Oct 25, 2009 at 5:55 AM, Frederic Bregier <fredbregier at free.fr> wrote:
>
> Hi,
>
> Yes, you get it perfectly!
> Additionaly, it ensures that at most one thread is running at a time for the
> same channel (for the ordered one of course).
>
> Cheers,
> Frederic
>
>
> vimana wrote:
>>
>> Thank you!! This definately helped me out!
>> One last thing. I just want to make sure I understand what the execution
>> handler is doing:
>> So when a request comes in from the client, the execution handler receives
>> it and fires off the business logic handler in a new thread. From there
>> the business logic handler can do all its lengthy calculations and not
>> worry about blocking the execution handler which is responsible for
>> handling the i/o requests.
>>
>> Let me know if that's correct.
>>
>> Once again thanks for clarifying!
>>
>>
>> Frederic Bregier wrote:
>>>
>>> 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-tp3874876p3885401.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
More information about the netty-users
mailing list