Hi again,
Actually..I hashed out your first idea with two other guys and it seems like
it should work. Let me see if I got this straight.
1) When the action class is called..create a timestamp.
2) Create the stateless session class.
3) Get the javabean associated with the series of pages (session scope)
4) set the timestamp in the bean.
5) set the timestamp in the session.
6) do session logic.
7) check to see if the session timestamp and bean timestamp are the same.
8) if so, set the bean reference to the session return results
9) if not, ignore everything else...most likely the connection was lost
10) return jsp page
So in code it might look something like:
{
SomeSession ss = new SomeSession();
SomeBean bean = getBean(); // gets the javabean used by jsp page
Date date = new Date();
ss.setDate(date);
bean.setDate(date);
ss.doLogic();
if(checkDate( ss.getDate(), bean.getDate()) )
{
bean.setResults( ss.listAllResults() )
}
}
Is that good enough? You said something about a race condition. I recall
reading about this in my threading book, but I never was quite clear on it.
My assumption is that it would be possible for two thread/requests to
interrupt one another, thus in the middle of one thread checking the date,
another one could be altering it, or something like that.
Here is why I don't think this would ever happen. First, because each bean
is tied to an HttpSession, on a per-client basis, it would be almost
impossible for a client to submit to the same method in the same action
class at the same time..much less at least seconds apart. It is possible
that the two sessions do different amounts of work..such as one searching
for everything, and one searching for a few items..with both ending up
finishing at the same time. In this case..what to do?
There is one other thing to think about though. By actually fixing this
problem, we introduce another one. By allowing a user to hit STOP on the
browser and submit the form again, each request (at least in our case) will
pull a connection from the connection pool. If you have one user that
submits, stops, submits, stops, etc..and possibly several sessions (not
http..but logic session classes) running on the server for just a single
user..its very possible we will run out of connections in the connectin pool
(our own home brewn class right now). We did add some code that will open
new connections, but until we move to EJB and have the container manage all
of this, it can get quite bad if too many requests from one user keep going.
Ofcourse, at some point the session/logic class thread will be done and the
connection will get returned.
However, my thinking is..a J2EE web app is like an application. The user
shouldn't be prevented from stopping a form right after its submitted..maybe
they see something they forgot, or some wrong info. If it was a desktop
application..they could stop it, change, and restart the transaction (unless
its using RMI or CORBA or something to talk to a logic tier of servers). So,
I think as a web-application, they should be able to do this too. If this
means we should have 1000 connections in the pool (hopefully not), then so
be it..but the end user should never be burdened because we simply only
allow them to do one transaction at a time. We did however allow them to do
one transactio per module on our site..meaning, if they were to send a fax,
and check for an invoice, each one is a separate module..so they could get
away with doing each one of those at the same time.
Anyways..I look forward to what you have to say about my understanding of
what you said in the first email reply, and see if I am on target with
implementing this.
Thanks again.
>
>
> On Wed, 15 Nov 2000, Duffey, Kevin wrote:
>
> > Thanks for the reply..
> >
> > Your idea has some merit..the only problem is, we have so many different
> > searches and profile updates that could be happening..I would
> need to keep
> > track of each of those separately.
> >
> > Here is what I had in mind if there isn't any way to detect
> ahead of time
> > that a connection to the browser was terminted.
> >
> <snipped>
>
> I think your proposed solution seems kinda kludgy (either that, or I'm a
> bit slow and don't fully understand it...) also as you said it only tracks
> two references, and can be foiled by starting 2 long running searches,
> aborting them, then doing a quick third one.
>
> You don't need to keep track of each request, you just need to provide
> very basic tagging of results so they can be verified against requests.
>
> A slight variant: Instead of passing in the timestamp have the bean return
> one as part of the result, which you could then sanity check to ensure
> that the timestamp in the session is before the time the search bean
> thinks it started. If you get a mismatch, then discard the results as
> they're stale.
>
> This does leave a race condition, where the critical section is in between
> placing the timestamp in the session and the search bean creating its own
> timestamp, you can minimise this by synchronising your code up to (but not
> including!) calling the search bean, and creating the 'result' timestamp
> first thing in the search bean method.
>
> > >
> > > Here's another approach.
> > >
> > > Put a timestamp in your session to denote when a search request was
> > > started, and have the searcher object track this timestamp
> > > too. When you
> > > get the results back, check that the timestamps match before
> > > populating
> > > your bean. If another search had happened in the meantime, then the
> > > timestamps won't match, and so you can ensure that no
> > > mismatch happens.
> > >
>
