Alex Burmester wrote:
Hi all, I have a server built on mina that is currently a fully
asynchronous message router for an in house protocol. It's fast and it
works very well. I need to add a bit of complexity to it unfortunately
and I want to make sure that I don't screw up the fast and working well
part of it ;-)
For a subset of my incomming messages I need to add a database lookup
which unfortunately involves a blocking jdbc call. I'm planning to use an
apache commons connection pool.
My server currently uses the SimpleServiceRegistry so it gets the default
thread pools for io and protocol. I was originally thinking of adding a
third worker thread pool and a queue to process the messages that need the
database lookup. Then I thought if I just keep track of the number of
outstanding database lookups and keep that number within a limit and
reject any messages beyond the limit with something like a queue full
message. This should allow me to use the protocol thread pool to also
process database lookups without starving the protocol thread pool in the
event of .
Just wondering if anyone has any thoughts one way or the other.
(separate worker thread pool for database ops or keep it simple)
I don't know your application and I don't have a lot of mina experience
but I would keep it simple ;-)
and just use the protocol thread pool.
Before starting premature optimization, try to define "database
slowness" and test if the lookup is really "too slow"
for doing synchronously.
Maarten
