Re: seda Database access

Hi Jared,

I will offer a comment in parallel to that. I have been thinking myself about that and I suggest
you consider:

1-that a robust db driver may be more important than its throughput, so watch out for error in
tweaked jdbc drivers.

2-that you simply can't let the number of db connexion get too high. Seda is appropriate when
trying to serve 1000 clients with 100 thread. But seda as a client, it may be killing your DB
server if it is not itself capable of sustaining a high number of connexion (can you image 1000
connexion with 100 thread? Sure it is feasible but... the DB will turn red hot...). So you would
limit your connexion pool to N, and limit your DB stages thread pools to a total not exceeding N.
And if both numbers are equal, then you don't need a seda DB driver, just a regular driver 1-to-1
thread-to-connexion).

3-that any asynchronous api EMULATION over a synchonous one, requires threads anyway. So you might
simply want to write a DBWorker stage that has a bounded thread pool, instead of getting into
complex thread manager stuff. But that is just my opinion.

I would like to hear others on that.
Hope this helped.





--- jared allen <[email protected]> wrote:
> Hi, I’ve read in some of Matts papers and past posts to this list that
> you had at one stage implemented a stage that acted much like the async
> file stage , but instead accessed a database (mysql etc) , is there any
> chance you still have that code? 
>  
> It would be a great start as I will be implementing such a stage in my
> project.
>  
>  
> Jared Allen
>  
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01