Is this PetStore component imp: is efficient ?

[Raees Uzhunnan]

PetStore implements catalog as stateless session bean holding catalog and catalog items. But in my opinion suppose a pool of (100 ) stateless session beans having 1000s catalog items may potentially be a bad solution because the memory it may consume. Isn’t it good if only one catalog would have been maintained and shared among catalog session beans for better memory utilization since the list is static. If so how it can be dine ?. is there any potential problem in doing so ?

[Rufus BugleWeed]

Pet store is a demonstration project. It's to show off technology.
If your stating the catalog has static content how would you feel about implementing it with an LDAP based solution?

[Raees Uzhunnan]

Its not ideal giving another $50000 solution. An architect should leverage existing investment for the solution
Raees

[Raees Uzhunnan]

Please some one give me some thoughts about this

[Tom Chen]

Originally posted by RAEES UZHUNNAN:
Please some one give me some thoughts about this

Hi Raees,
I've been studying the Pet Store 1.3 these days. I'm very interested in your topic. Would you please explain more detailed for your question? Which version of Pet store you are talking about?
My understanding is that the number of stateless session bean in the pool can be confiugred in the application server. You can configure your pool size of catalog statless session bean based on the number of clients, server capability, quatity of catalog etc.

Tom
[ January 07, 2003: Message edited by: Tom Chen ]

[Raees Uzhunnan]

Hi Tom,
Let me get this straight
When we use stateless session bean for catalog (static contents) access. There are 2 options the way catalog can be loaded and presented from database.
1.When the bean is instantiated, load the catalog and store it as a member
2.Load the catalog every time the getCatalog() method on the bean is invoked
Both methods have it�s own disadvantage. The first hogs a lot of memory if the catalog is large and more bean instance have to be pooled. The second will make the bean to hit database every time it is accessed.
Is there a way the catalog can be instantiated once and shared among the stateless session beans using a storage place something like a servlet context?.
Since the catalog is static, synchronizing access is not needed.
Is it okay if we load and store the catalog in JNDI when the first instance of the stateless session bean is created and the rest in the pool share the same catalog object ?.
Just a thought, please provide your expert advice

[Sanjay Raghavan]

Raees,
You had actually answered your question in the original post itself...
"Isn�t it good if only one catalog would have been maintained and shared among catalog session beans".
Can you give some thought as to how to achieve that?
Is there any Design Pattern that you can use here?
Ok, so obviously you do not want to retrieve catalog info from the db each time a SLSB instance is given to the client.
Let's look at the singleton pattern. How can you use it to solve your problem? Retrieve all your static data into a convenient form (value list, enumeration, what have you) and cache them in a singleton.
Each time any SLSB that needs static data is created, you request the necessary data from your singleton.
HTH.

[Raees Uzhunnan]

Sanjay ,
As you know EJB does not allow static data fields , I don’t know how you can implement Catalog as singleton.
The alternate would be as I said in my last reply to put in JNDI tree and referencing from there makes JNDI to maintain single copy. I do not know what would be a J2EE experts advice in this case is
Awaiting your thoughts
Raees

[bor]

Hi, Raees
Give you a direction. Please think about "how do you deal with the huge static data in your system?" Then think about "how to generate the data there."
Hope helpful.
Sincerely,

[Sanjay Raghavan]

Raees,
I found a code fragment on a different forum, authored by a one Sean Johnson. I haven't looked at it in detail, but see if this addresses your problem.

----------------Code Fragment---------------------
RE: Caching data Sean Johnson
You can store the data in a singleton class that you access
from your stateless session beans.
class MyStatelessSessionBean extends ...
{
public String getReadOnlyTableData1()
{
MySingleton singleton = MySingleton.getInstance();
return singleton.getData1();
}
public int getReadOnlyTableData2()
{
MySingleton singleton = MySingleton.getInstance();
return singleton.getData2();
}
.... etc.
}
class MySingleton
{
//Singleton instance
private static MySingleton singleton = null;
//Read-only RDBMS data
private String data1;
private int data2;
... et cetera
//Private constructor!
private MySingleton()
{
//Read the read-only RDBMS data here
}
public synchronized static MySingleton getInstance()
{
if(singleton == null)
{
singleton = new MySingleton();
}
return singleton;
}
public String getData1() {return data1;}
public int getData2() {return data2;}
... et cetera
}
-----------------End of Code Fragment------------
HTH.

[Thomas Taeger]

Hi Raees,
... see below ...
Thomas.
[ September 15, 2005: Message edited by: Thomas Taeger ]

[Thomas Taeger]

Hi Raees, quoting is not easy, sorry, so again:

Originally posted by RAEES UZHUNNAN:
... EJB does not allow static data fields...

As far as I know EJB does not allow _mutable static_ data fields, i.e. with unpredictable resource usage [over a long time period without the chance of freeing by ejbPassivate()...].
Often _final_ statics with initializers are the solution, ok. But some months ago I also tried (using Sun's J2EE reference implementation server) initializing once (i.e. if still null) like Sanjay Raghavan's does in his code sample, and I was able to store values created or read from system input into static data fields once. (I am not feeling very firm about more backgrounds.)

... to put in JNDI tree and referencing from there makes JNDI to maintain single copy. ...

For me going via the slow JNDI would allways be the last choice if not advised by other reasons.
Thomas.
[ September 15, 2005: Message edited by: Thomas Taeger ]

[Raees Uzhunnan]

Thanks a lot Thomas. I think i am gona do this way
Raees