I see one additonal problem with the original aproach. If you don't set the buffersize big enough to hold the complete result of a request and there several includes that produce parts of the result you don't have control which include will be the last one to access the header before the header will be sent (resulting in 'response has already bean commited')
Regarding your answer: Wether reading the date from the database is a significant overhead depends on the kind of the database query. If the time is mostly spent in the query and not in the get/release call, the connection pool doesn't help much. I see a further problem with this approach: To get the last modified date from the database the controlling servlet needs the knowledge how to get it (It must know what the includes do). This is a bad design (in my opinion). I think it's better to design the includes in a way that they store the last access time in common place (e.g a bean with request scope) and the controlling servlet just reads this value. (This again will only work if the > -----Urspr�ngliche Nachricht----- > Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 14. Juni 2002 06:28 > An: Tomcat Users List > Betreff: Re: flush="false" not working? > > By the way, doing the extra read to get the last modified date in the > controlling servlet or page is not a significant overhead > with properly designed use of a connection pool. > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
