usage of stateful session beans

[Saha Kumar]

Hello all,

I have the following questions:

1) I have read that a ValueListHandler is a SFSB. I also want a SFSB for a shopping cart. Is this considered too many SFSBs per customer or travel agent?

2)
I have the following:

a) Client -> BD -> SLSB (Session Facade) -> SFSB (Shopping Cart)

in the case above, I would have the SFSB handle as a parameter to each method of BD, SLSB.

The alternative is:

b) Client -> BD -> SFSB (Shopping Cart) -> SLSB (Session Facade)

which defeats the purpose of the SLSB (session facade).

Which is preferred, a) or b)?

3) Where should the Customer object be cached? Is it acceptable to create a SFSB which contains both the Customer object and a pojo shopping cart?

Many thanks for any help.

-Saha

[Rama Bhargav]

1) I have read that a ValueListHandler is a SFSB. I also want a SFSB for a shopping cart. Is this considered too many SFSBs per customer or travel agent?

I assume you are thinking of ValueListHandler for retrieving the itineraries stored in DB. Practically speaking, I don't think we need to use this ValueList pattern as it won't be necessary to provide the pagination. Ideally, no customer will have more than 20 itinearies with date >= current date.
Hypotetically assuming that we SHOULD use this pattern (irrespective of suitability), I would prefer to use one SFSB which will store both shopping cart and the ValueListHandler with DB data, instead of two separate SFSBs.

2)
I have the following:

a) Client -> BD -> SLSB (Session Facade) -> SFSB (Shopping Cart)

in the case above, I would have the SFSB handle as a parameter to each method of BD, SLSB.

The alternative is:

b) Client -> BD -> SFSB (Shopping Cart) -> SLSB (Session Facade)

which defeats the purpose of the SLSB (session facade).

Which is preferred, a) or b)?


I would go with option a. Option b does not make sense, because your client needs to access SFSB data, then why would SFSB calls SLSB facade? If SFSB needs to use some services (like calling a DAO), it can call those services directly instead of calling the SLSB facade.

3) Where should the Customer object be cached? Is it acceptable to create a SFSB which contains both the Customer object and a pojo shopping cart?

I would store a key like customerId in the SFSB instead of storing the entire customer object. SFSB could use findByPrimaryKey(custId) on Customer entity bean. This provides faster access to customer object, while not having to keep another copy of the Customer in SFSB.

[Saha Kumar]

Hello Rama,

Thank you for the helpful post.

I wanted to use the ValueListHandler to contain the flight data returned to the customer in the prepare itinerary UC. Subselects could be made on this data (instead of requerying the db). Do you think the SFSB is worth using for this purpose?

Hypotetically assuming that we SHOULD use this pattern (irrespective of suitability), I would prefer to use one SFSB which will store both shopping cart and the ValueListHandler with DB data, instead of two separate SFSBs.

I thought the ValueListHandler is defined to be a SFSB so that the SFSB described above would contain 2 objects: shopping cart and another SFSB, ValueListHandler. Am I correct in my understanding?

So what I am gathering is that we have a SFSB which is used to store various information accumulated during the customer's/agent's session. That makes sense. The objects in the SFSB are all POJO-based. Is my interpretation correct?

Thank you in advance.

-Saha

[Rama Bhargav]

I wanted to use the ValueListHandler to contain the flight data returned to the customer in the prepare itinerary UC. Subselects could be made on this data (instead of requerying the db). Do you think the SFSB is worth using for this purpose?

My take on this is not to use ValueListHandler, because I don't think there will be many filghts when you query based on based on departure, destination and datetime. Even for a big airline operator, I don't think there will be more than 20 flights that would match the seach criteria. If there is any likelyhood of getting more records, we should use ValueListHandler.

I thought the ValueListHandler is defined to be a SFSB so that the SFSB described above would contain 2 objects: shopping cart and another SFSB, ValueListHandler. Am I correct in my understanding?

I am thinking of "HAS A" relation instead of "IS A" relation between SFSB and valueList handler. SFSB will compose ValueListHandler and shoppring cart objects.

So what I am gathering is that we have a SFSB which is used to store various information accumulated during the customer's/agent's session. That makes sense. The objects in the SFSB are all POJO-based. Is my interpretation correct?

Yes, I agree.

[Rama Bhargav]

My take on this is not to use ValueListHandler, because I don't think there will be many filghts when you query based on based on departure, destination and datetime. Even for a big airline operator, I don't think there will be more than 20 flights that would match the seach criteria. If there is any likelyhood of getting more records, we should use ValueListHandler

I take this back. I just did a search, there are more flights than I thought. ValueListHandler comes handy for this situation.

[Saha Kumar]

Hello Rama,

Thank you for your well-researched response. In the case where we use the ValueListHandler (SFSB), I guess the handle to the VLH could be stored in the SFSB that we're using for the customer's or agent's session info. We will have 2 SFSBs per logged-in user.

What do you think?

-Saha

[Rama Bhargav]

Saha,

I would still have only ONE SFSB which will act as the container per logged in client specific data. This SFSB will hold references to VLH and shopping cart.

My proposed use of SFSB is as a container for user specific data ( just like httpSession). We can store all the data that is needed and nullify the contents that that are no longer required (for ex, when the user is done with tranversing thru all the flights info matching his search criteria, we can nullify the VLH in SFSB so that it will be garbage collected).

I am not sure why you fee the need for two different SFSB? Can you please eloborate why you feel we need two SFSBs as opposed to one?

[Saha Kumar]

Hello Rama,

Thanks for the reply. I was thinking that a VLH had to be in a SFSB. I reread the Sun description and I believe SFSB was only a suggestion. Since then, I have changed it similar to what you have.

Don't you need to store the Customer object in the SFSB?

Thanks.

-Saha

[Rama Bhargav]

Saha,

Don't you need to store the Customer object in the SFSB?

My thinking is that, when a customer logs in, we will be doing a findByUserId() which will load the matching customer entity in memory. So if the SFSB only need to store the customerId (Primary Key value). Since customer entity is already available in memory, why not use a findByPrimaryKey() method on customer entity bean local Home interface instead of making a copy of the same customer and storing it SFSB.

So the SFSB will store customerId instead of the customer object.

[Saha Kumar]

Hello Rama,

That's a good point. It takes advantage of EJB entity feature and is less for us to manage (in the SFSB). Thank you!

-Saha