Rama Bhargav

Greenhorn
+ Follow
since Mar 25, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rama Bhargav

how can you store 1-m relationship without adding a new table. I've thought about it...now ..so are you assuming that each segment will have just 1 parent segment. There can be more.


No, I did not assume each segment will have just one parent segment. I was only trying to make the point that you do not need the DB table/entity concept called "Route". Since each segment can have multiple parent segments, this leads to many-many relation of Segment table to itself. We would need to resolve this with association table.


How can this be represented with just one table. Relationships are required to show these layovers. But you can always state that as an assumption. My question is with 2 tables seems not possible unless you have a column which takes multiple values or something like that making it bit wierd



As you rightly pointed out, we can not achieve this with just the segment table. I am thinking of SegmentRelation table which will have segmentID and the corresponding parentID columns. So, we would end up with the following DB tables
1) Segment
2) SegmentParent(Association table for Segment as each segment can have more than one parent segment)
3) Flight
4) SegmentFlight (Association table for Segment and Flight as they are in many-many relation)

When it comes to modelling your domain classes, you do not need to introduce additional entities other than Segment and Flight to satisfy the above requirement.

for a route-->there are segments and for each segment there is a flight.
Without a route table, flights and segments cant be correlated.



My initial design included "Route", but the more I thought about it, I realized Route is nothing but a segment which has one or more than one segment. For example, Consider the Route NY-->LA.
1) This route has two segments NY-->Dallas and Dallas-->LA.
2) The same route if flown directly has only one segment NY-->LA.

This relation can be accomplished if segment table references itself for sub/child segments. Like in Employee table, each employee can have a manager who is also an employee. In Segment table, each segment can have a reference to all feasible child segments. This would eliminate the need for a separate Route table. This is my current understanding of the Route and Segment. Hope this helps.

Do I have to represent all entity beans and utility classes in the class diagram or can they be shown as part of component diagram ?



As far as my understanding goes, class diagrams are best represented as technology neutral. So it is not a good idea to show entity beans etc.. which are techology specific.


I am plannig to extend BDOM to some extent and represnt the class diagram which focussues on business domain alone. Is this correct.



I agree with you. You can extend the BDM and present any assumptions you may have made in the Assumptions section.
Saha,

I agree with you. But for the pay method, I am not sure what you intend to do in the undoTransactionalTask(). Any transaction aware operations such as database manipulations you performed within the TX boudaries will not be committed if there is an unhandled ejbException.

In case of SFSBs with CMTs, if you want to restore the SFSB state to the previous state in case of a transaction rollback, your SFSB has to implement SessionSynchronization interface.


pay {
try{
nonTransactionalTask();
transactionalTask();
}catch (SystemException se){
undoTransactionalTask();
throw se;
}
}


I wanted to commit an update in one use case, and then continue on and commit a second update.



If I understand you correctly, you want to have two different transactions in one server trip. You can accomplish this using CMT also as expalined below.

facade1.save(). TX Attrib: TX_REQUIRES_NEW / TX_REQUIRED
facade2.update(). TX_REQUIRES_NEW / TX_REQUIRED

facade1.saveAndUpdate(). TX_SUPPORTS. This method calls facade1.save() and facade2.update().

If your client calls saveAndUpdate() without any client initiated TX context, then save() method will be executed in its TXN, then once it is finished, facade2.update() will be run in its own txn.


I also wanted (if possible) to use only one SLSB per round trip from client to server and back to client. I did not want one use case facade calling another use case facade. I am hoping this design choice provides better response time and is worth the extra effort. What do you think?



I agree that there should be only one network trip to server for one client request. However, about one facade calling another another facade, it depends on how you design and delegate responsibilities between Facades and POJOs. I will have my facades with useCase level methods such as saveItinerary, priceItinerary etc.. which inturn delegate to Application service classes. My facades would handle the Transactions using CMT as explained above.


- A SLSB is executing code without CMT or BMT

- The SLSB instantiates and calls a method in a POJO with its javax.ejb.SessionContext as a parameter.

- The POJO uses context.getUserTransaction() to start a transaction, then performs a database update.

- The POJO then instantiates and calls a method in a different POJO which then executes some code in the same transaction.

- The second POJO returns to the first where the transaction is either rolled back or committed



I am not sure why you did not want to use CMT. You could use CMT by having a method in SLSB start the Transaction. The flow goes like this.

SLSB method() starts the transaction and calls --> Pojo1.methodX() --> pojo2.methodY(). The transaction context will be propogated thru the thread of execution all the way. This way, you do not have to demarcate the transaction boundaries programmatically with txn.begin(), commit() or rollback().
Anybody, pl reply if I am on the right track or not.
While drawing the class diagram, if we have two classes in many to many multiplicity with each other, is it mandatory that we need create an assoication class for this? If not, when and why do we create an association class?

As far as I know, association class is created when it can hold additional info. For ex: Consider 2 classes, Student and Course in many to many relation.

1 Student enrolls in 0..* Courses
1 Course can have 0..* Students

Required Navigation is bi-directional.
So programmatically, this will be represented :
1) In class Student, we will have an array/list of Course Types
2) And Course class will have an array/list of Student instances

However, if are required to hold additional fields about this relation like payments made by student for a particular course, we will need to capture this in an association class as this payment info does not fit into Student or Course, because this is an attribute that depends on the association of Student and Course.

Let me name this association class as "StudentCourseDetail"

One Student can have 0..* StudentCourseDetail (Assocation classs) objects
One Course can have 0..* StudentCourseDetail objects

Programmatically, this translates to :
Student class will have an array of StudentCourseDetail
Course class will have an array of StudentCourseDetail
StundetCourseDetail will have 1 studentId, 1 courseId, and some additional attributes that depend on the student to Course relation like payment made by the student for that particular course.

Please correct me if I am wrong and feel free add your insights.
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,

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?
Congratulations Sanjay.

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.

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.
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.