<<
user accidentally double clicks one of the
links and the same business object gets two requests, where the first isn't
finished before it recieves the second.
>>
This probably better be intercepted, even if the logic is thread safe.
Too confusion to the client. You can watch user activity thread in
your session object.
----- Original Message -----
From: "Russ Freeman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 6:59 PM
Subject: Re: multithreaded beans, struts, doing it right...
> Kind of :) In fact your solution isn't far away.....
>
> I am currently supporting multiple threads of activity within the same
> browser window and hence session.
>
> Let's say we have a big table on a page with two columns, where each
column
> is like a "view". Each column view is displaying a different aspect of
some
> business data and each column/pane has its own set of links too.
>
> If the user clicks a link in the left pane, the URI is sent with ID 1
> encoded in the URI and if they click a link in the right pane, the URI is
> sent with ID 2 encoded in it. (The ID is a lookup into a Map of business
> objects). This is similar to what you were saying I think.
>
> However this works OK until the user accidentally double clicks one of the
> links and the same business object gets two requests, where the first
isn't
> finished before it recieves the second. So far I have ensured that each
> business object is thread safe and I have yet to detmine if this will work
> or whether I have just covered up another problem!
>
> Does this help?
>
> Cheers,
> Russ
>
> ----- Original Message -----
> From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Russ Freeman" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 19, 2001 11:24 PM
> Subject: Re: multithreaded beans, struts, doing it right...
>
>
> > By multiple threads of activity do you mean the user has multiple
windows
> > open? If so, perhaps in the user's session you could have a Map of
> business
> > logic beans instead of just one. And somehow have the client identify
> which
> > thread of activity the currenty action is part of, from there get the
> > apprpriate bean and you're back in single-threaded mode (o: Then again,
> if
> > this isn't what you mean, then thats probably no use!
> >
> > is that what you mean?
> >
> > cheesr
> > dim
> >
> > On Wed, 20 Jun 2001 08:08, Russ Freeman wrote:
> > > Hi folks, I have a question about building robust beans.
> > >
> > > Context:
> > > Building a Model-2 application with tomcat that uses a home-grown MVC
> > > framework (probably going to replaced with struts).
> > >
> > > My concern is over the design of my business logic beans, which are
> > > stateful controllers. Each of my user sessions can have one or more
of
> > > these beans and each represents a separate thread of activity for the
> user.
> > >
> > > This is working OK except for the threading issue in that multiple
> requests
> > > (accidentally) sent the to same controller cause obvious problem. I
have
> > > since added a level of synchronization and am hoping this will deal
with
> > > most problems. Something I certainly don't want to do is to move away
> from
> > > stateful controllers (to avoid the threading problem) because I
believe
> > > this is the right approach.
> > >
> > > Also from reading the struts docs carefully it appears that this is
> still
> > > something that must be considered with struts, i.e. once the Action
> object
> > > has passed on control to a bean, the bean has the concurrecy problem
to
> > > deal with.
> > >
> > > So,
> > > I would be interested in people's opinion on their approach to
managing
> > > concurrency in controller/business logic beans.
> > >
> > > Thanks in advance,
> > > Russ
>
