how to delay on this situation?

Ah, that makes loads more sense, thanks.

The principle of putting the thread that's servicing the incoming request is sound, but a problem arises if your malicious user sends multiple requests simultaneously.

You need to arrange to discard the "spare" offending requests, because if you create and block a thread for all of them that will cause you to run out of resources.

(edit) You don't necessarily need to use a Session, but you DO need to uniquely identify your incoming users. That can be by cookie. You could also take the approach of blocking by IP address (that can cause problems when one IP address is shared by a large number of users).

dcmintera at 2007-7-9 6:21:33 >

> i think it can be done with sessions

Which proves only that you don't know how they work. How do you imagine the server keeps track of which user owns which session?

Bingo: generally a cookie (look for JSESSIONID). There's no quick fix here.

All the mechanisms that can be used to maintain a distinct session are susceptible to abuse by a malicious user. IP address identification isn't, but risks unfairly penalizing a user who's sharing an IP with an idiot.

dcmintera at 2007-7-9 6:21:33 >

got the idea but didnt understand about searching for ip adresses...they wont be stored in a db?will they?

you talked about jsessionid..i am searching about it but couldnt get valueable info...if you have any link write it and i will be very appreciated...

thanks a lot again

Burak

netsonicca at 2007-7-9 6:21:33 >