I find it a very interresting question to try to avoid
blocking of for example jdbc calls. Has anybody done
any code?
I had the same problem when simulate a 3th party request. In my demo, the
server receive request for a quote, so the server need to ask a quote to a
3th party and when I receive the quote from the 3th party, I send to
response back to the client.
but I don,t want it to by blocking so I use a callback method that will
receive the response from the 3th party.
2008/6/26 John ROM <snake-john_at_gmx.de>:
> Hi Matteo,
>
> >
> > The Selector thread (N+1 threads per N Cpu) handles the ACCEPT operation
> > for
> I think this is configurable.
> if you start one controller out of the box
> it is only one thread.
> > each new connection, stores the connection reference (selector key) then
> > passes it to a new thread for the protocol filtering (which is the
> parsing
> > action in the case of a text based protocol like an xml-based one,
> > right?).
> > At this point, say the client sent a command "doSomething", which results
> > in
> > several operations to be performed by the server (eg. Querying a db,
> > creating some object instances and so on). Are these operations done by
> > that
> > same thread or is it a new thread different from the one that filtered
> the
> > protocol?
>
> These operations are done by "the same thread that filtered the protocol"
>
> Of course you often then end up blocking on jdbc calls.
> So you loose some of the "Threading" advantages you gained by NIO.
>
> I find it a very interresting question to try to avoid
> blocking of for example jdbc calls. Has anybody done
> any code?
>
> Many Greetings
> John
>
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>