----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
Assuming your servlet is thread-safe and all, the quick way is to
synchronize on the client session object. That way, multiple threads
cannot be handling requests from the same client simultaneously, but they
can handle requests from different clients simultaneously. Example:
void doPost(...)
{
HttpSession session = req.getSession( true );
synchronize(session)
{
// handle the request
// any other thread that tries to synch on the
// same instance of session will block
}
}
I don't think this will make for great performance, though. Let's say
your fast-refreshing user spins up 3 threads waiting on their requests ...
those are threads unavailable to service other clients. Long term, you
might want to think about something like caching the output from your DB in
the session object, and when a request comes in and you have data in the
cache, just send the cached data and don't hit the database. Of course,
you need a timeout for refreshing the cache, so on and so forth.
- Fernando
At 09:35 PM 12/8/99 +0005, you wrote:
>----------------------------------------------------------------
>BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
>WHEN YOU POST, include all relevant version numbers, log files,
>and configuration files. Don't make us guess your problem!!!
>----------------------------------------------------------------
>
>Dear Nick
>
>I greatly appreciate your detailed response to my problems.
>Unfortunately you don't address the issue which worries me the
>most.
>
>My main question is whether there is a built-in way of protecting
>oneself from a user who refreshes his browser many many times?
>
>(I should have left all the other questions for other threads.)
>
>I'm contemplating running a time check on the session object and
>forcing the user to wait 5-10 seconds before using the same servlet
>twice, but -- is this necessary? advisable? or even valid? Am I
>somehow circumventing default protections?
>
>
> > Are you intializing all your locally-scoped variables?
>
>I can't claim not to have missed one or two. But -- why do you ask?
>The site is quite comfortably serving a few hundred user's per day.
>So I don't see how your question is relevant. I'm busy confirming all
>the details so I can meet future demand. (In January it has to ramp
>up to 10s of thousands per day.) Perhaps, your question is
>relevant, but I don't understand how.
>
>
> > You should never synchronize "until desired consistency is
> > achieved". You should always know why you are synchronizing.
> > Remember when you say "synchronize", you are implicity saying
> > "synchronize(this)": the entire object is getting locked, not just
> > the method.
>
>The crude reality is that this is a VERY rush job. We are currently
>doing user testing. In future we will examine the 'sychronization'
>issues one by one. I was concerned that by sort of forcing a single
>thread model I was causing unexpected side effects. If so, I don't
>really understand how that would produce the behaviour I'm seeing.
>
>
> > Don't forget to commit every jdbc transaction, even "select"s:
> > because jdbc considers even reads can trigger writes.
>
>Interesting point, but MySQL has no 'commit'! What I'm doing is
>freeing my connections back to the dbConnectionBroker pool. Do I
>need to satisfy JDBC as well?? I hadn't thought of that.
>
>
> > And are you using a "finally" clause to ensure you are committing
> > and closing your cursor?
>
>Yes, absolutely, hence my severe concern over what I'm seeing! If I
>hit <ctrl-r> a half a dozen times then at least four out of six times, the
>code never executes as far as the 'finally' -- it just ceases to
>execute........ somewhere!
>
>Sure hope someone out there can help me, it's got me pretty
>worried.
>
>Rgds,
>
>Hasan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
