About 3/4 of the way down in the article 'j2ee design patterns' authored by
William Crawford and Jonathan Kaplan
http://www.devx.com/assets/download/7254.pdf
Read the 'criteria' 'convert your session beans into business delegates' --
very instructional to the scenario you have described
HTH
Martin-
----- Original Message -----
From: "croffman" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Thursday, June 09, 2005 3:49 PM
Subject: Re: Multiple user - problem
Thanks for the quick responses.
Here is some more info:
1. >>>>>Is it worse with more users?
This was done by manual users, before load testing. Couldn't try that now.
2. >>>>>Do you keep any non-synchronized user-specific info in an instance
of a class that is only instantiated once (like a servlet or action)? That
gets a lot of people even though it's in all the documentation.
Looks like there is a similarity. But not sure. Had a MAIN action class
(which extends from TilesAction), which contains a protected class defined
and that got the CDTO in it. Whereever needed in all the action classes, the
CDTO is got from this protected class. Is there any problem here?
3. >>>>>-synchronisation of all method calls
No where explicit synchronization is being used in the application.
4. >>>>>-scoping of data entities(assuming you are implementing with beans)
Kept the forms in request scope.
5. >>>>Also - are you resetting all of the properties in your forms classes.
If not, some of the data set by one user can bleed over to another user.
As using DynaValidatorForm, not sure how to reset the properties.
In the app, are using Struts form-beans
(org.apache.struts.validator.DynaValidatorForm). And in the action classes,
calling the delegate by passing the cdto (custom data transfer object),
which contains the request data. And when the delegate calls the EJB's, it
gets the data from database and populates the custom data transfer object
and sent back to the action class. And in the action class, this cdto is
copied back to form.
The wrong data came up for one user only. Is there any chance that this cdto
is shared and being used for two users. Couldn't think of a chance, but...?
Is there any chance by POINT #2 above.
And EJB's are stateless and Entity Beans are with container managed
persitance.
Once again thanks for your suggestions.
Croff
----- Original Message -----
From: "Martin Gainty" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Thursday, June 09, 2005 2:22 PM
Subject: Re: Multiple user - problem
both concepts are applicable in that
scoping of session based information should ultimately pull from
user-neutral entity (such as Class Object) whose end of life is not
dependent on either client session passivation or client session
termination
Any underlying synchronisation mechanisms for entities (synchronised
objects) are entirely dependent on selection of scope and
whether the implementor is controlling the object via declarative or
programmatically means
Here are some good reads
Problem Scenario for Stateful Session Beans
http://docs.sun.com/source/817-2162-10/bpstatement.html
Software Architecture in Practice: The Luther Architecture
http://www.awprofessional.com/articles/article.asp?p=32063&seqNum=3
HTH,
Martin-
----- Original Message -----
From: "Dave Newton" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Thursday, June 09, 2005 1:47 PM
Subject: Re: Multiple user - problem
> Martin Gainty wrote:
>
>> -synchronisation of all method calls
>
> Why all? (Really, why _any_, since you can synchornized any shared data
> structures.)
>
>> -scoping of data entities(assuming you are implementing with beans)
>
> Unless he's storing user data in application scope, this shouldn't be an
> issue, should it?
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
