Mutual Object for all users

[Alex Tosh]

Hi there,
we need to provide an object within our J2EE-Architecture that stores a value (this is indeed not a very difficult task ). This Object should be accessible & the relevant attribute should be read/writable for all users of the application. The object should not be an entity bean - no persistent storage is needed - and it has to be thread-save. What would you recommend to use? Something like the ServletContext-Object in a web-app?
Thank you
Alex

[Dana Hanna]

I would just use a static property of an object. Like this:
public class AppProperties {
private static String myProp = "default";
public static String getMyProp() {
return myProp;
}
public static void setMyProp(String newVal) {
myProp = newVal;
}
}
Then you can get it from anywhere by using:
AppProperties.getMyProp();
and set it using:
AppProperties.setMyProp(newVal);
This really isn't a J2EE question, just a beginner Java question.

[Alex Tosh]

I knew about the usage of static variables; that's not new to me.
But I was wondering if there is a possibility to use an application-context variable in the EJB-container - as is exists is the web-container (ServletContext-object).
Maybe the question was not exact enough.
Thank you anyway
Alex

[Kyle Brown]

There's a reason that neither the application context (which you can't access from the EJB container, btw) or static variables will work for this -- neither one will work in a clustered environment.
You say there's no need for the value to be persistent, but in fact making this an entity bean is probably your best, most scaleable option.
Kyle

[Alex Tosh]

Hi Kyle,
thank you for this comment - that's an interesting one. What about performance using an entity bean - what exactly happens when you update a record in an entity-bean. I read that the entity-bean instance gets a flag beeing not valid anymore. The next request initiates a new instance of the entity-bean which makes the hole thing quite slow. Is this correct?
cheers
Alex

[Nitzan Levi]

hi,
it's very importent to know what's the future use of the application. if it's a small application that will always run on a single server then you can use the static approach that will be the simplest and with less cost.
if your application needs to run in a clusterd environment than you need a more copmlex solution and the entity bean will be a good one. the cost of an entity bean (if you dont use persistence) is minimal for that complex environment !!
like every solution there's a pro's end con's the best solution depends on the requierments

[Alex Tosh]

Hi Nitzan,
thank you for the tip. I don't know yet if the app will run in a clustered environment, but to assure that it will run everywhere, I'm going to use an entity bean.
regards
Alex