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,
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
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
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
Thats a good approach to take for things like a "list" of items, such as a
search engine or a list of rows from a table. But what about when your
building up a single transaction, and you need to keep the state of several
pages across requests? While there is even less of a chance of what I am
On Wed, 15 Nov 2000, Kevin Duffey wrote:
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();
How about you have one hidden form field which is a unique key that
identifies the bean that should be used
Basically a user's session would have some sort of hashtable in it
containing a number of beans keyed by your hidden form field?
Then you dont have to send heaps of data around when doing
