• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

question on search using DAO

 
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I use the search with a POJO-->DAO, is it recommended to using plain DO or composite Entity Beans to create the search result VLH results.

IF I using the Entity beans I have too much of unnecessary resource utilization of creating EJB's.
If I use the plain DO : too many of java objects instantiated in memory which are not resource managed by the container..

Not sure which is the right way to go with this.

Thanks
Dhiren
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

IMO you need to combine both, i.e. use Value List Handler for getting outline lists and create EJB to see the details of an individual record. Once a customer wants details, it is likely that they are going to buy and so it's worth "investing" in an EJB.

So:

1. Use VLH to get a list of flights.
2. Customer chooses a flight and want to see seats, and other flight details.
3. Create a FlightEJB for that flight.
4. VLH gets a list of seats for that flight.
5. Customer chooses seats.
6. SeatEJBs are created for the chosen seats.
7. The chances are that the customer will now buy tickets.

What do you think?

Alastair
 
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dhiren Joshi:
If I use the search with a POJO-->DAO, is it recommended to using plain DO or composite Entity Beans to create the search result VLH results.

IF I using the Entity beans I have too much of unnecessary resource utilization of creating EJB's.
If I use the plain DO : too many of java objects instantiated in memory which are not resource managed by the container..

Not sure which is the right way to go with this.

Thanks
Dhiren




(a) Yes it is highly recommended to use create plain TO or VO in VLH Pattern.
(b) Yes you are correct too much (extremely high) resource utilization if you start creating composite entities and maintain in VLH. This defeats VLH.
(c) Do not worry about resource utilization of plain TO/VO. Part of life.

I am not using VLH but would recommend that you do mention in your assumptions that the system will present only first 25 or say 50 flights per direction.
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi-
Regarding the search , I am planning to use a statless session bean which build VO.

Any comments


Ranjeeth
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So:

1. Use VLH to get a list of flights.
2. Customer chooses a flight and want to see seats, and other flight details.
3. Create a FlightEJB for that flight.
4. VLH gets a list of seats for that flight.
5. Customer chooses seats.
6. SeatEJBs are created for the chosen seats.
7. The chances are that the customer will now buy tickets.



Deepak,
Whats your opninion about the above where I could use both a TO VO and then move to EJB's during the detailed work flow.
Is it possible to continue further down the work flow without creating EJB's I think not .
What r your thoughts ?
Thanks
Dhiren
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is my confusion too. If using VLH to get a list of flights, isn't the detailed info (even including the price) for the flights retrieved all at once? Later when clients need to choose a particular flight, it only needs to get its seats through a SeatEJB. So why do we need to create the Flight entity bean? I guess maybe we have to in the sense of Itinerary-Segment-Flight relationship.

Confused. Any explanation is welcome.

Thanks,
Annie
 
Alastair Calderwood
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wasn't sure whether a FlightEJB was needed. But then I thought that if the last seat on the flight were booked by someone other than the client, after the flight had been retrieved, but before the seat had been chosen by the current client, the flight would be no longer available, and would then be marked as unavailable in the flights database.

Using an entity bean, the client could be informed immediately, before being directed to the "choose seat" dialogue, and then finding that there were no seats left. That might not matter, it's just an opinion. I think you can include FlightEJB or not, so long as assumptions are stated.


Alastair
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was not planning to make the flight/seats an entity EJB (composite).
Only the itinerary/segments/bookedseats will be entity beans or 1 entity Composite.

because:
If you know what seats are booked then you will also know what seats are available and...If all seats are booked then the flight will no longer be available. So IMO persisting only the itinerary/segments/bookedseats will
give you all the info you need.

doesn't this imply that the Flight/seat composite does not have to be an entity bean; but should be POJO-DAO?
(At the moment I am not planning to use VLH)
Does this make any sense?
thanks,
J
[ January 26, 2005: Message edited by: Josep Andreas ]
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I was not planning to make the flight/seats an entity EJB (composite).
Only the itinerary/segments/bookedseats will be entity beans or 1 entity Composite.

because:
If you know what seats are booked then you will also know what seats are available and...If all seats are booked then the flight will no longer be available. So IMO persisting only the itinerary/segments/bookedseats will
give you all the info you need.

doesn't this imply that the Flight/seat composite does not have to be an entity bean; but should be POJO-DAO?
(At the moment I am not planning to use VLH)
Does this make any sense?



Josep,
that is the exact same problem issue I am trying to sort out.
Whether Flight/segment/seat should be a composite or a POJO-DO.
This is what I have thought of so far..
Since it is not involved in the really objects creation ..let them be POJO-DO.

Once the seats are booked make those creations via composite entities.
Does that make any sense. I am still confused about it.

Thanks
Dhiren
 
Josep Andreas
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes,I am making:
1. Flight/(equipment)/seat -> Composite view: POJO-DAO
never has to be persisted!
In the DAO you check which seats are booked (via some sql join query,
you can set reserved/unreserved property of seat..)
2. itinerary/segment/bookedseat -> Composite entity BMP/DAO

What do you think?
J
[ January 27, 2005: Message edited by: Josep Andreas ]
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Josep,
Thats what I am going to go ahead with now too.
I have changed my sequence diagrams so many times hopefully this time I get it right.
I will now go ahead with this solution.
Thanks

Dhiren
 
Annie Zhang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess there is already some discussion for this.

Is there any particular reason why you choose BMP/DAO over CMP?

Thanks,
Annie
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why did you choose to use BMP/DAO instead of CMP?

I am thinking of calling the web service from a DAO. Anyone else doing that?
 
Josep Andreas
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Annie,
It was my understanding that for a composite enity a DAO was mandatory.
I can However find no proof of this on the SUN site.
in their example they use a DAO:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html

But in ejb2.0 it seems that you can use CMP for a composite entity:
http://sys-con.com/itsg/virtualcd/Java/archives/0902/cohen/
(I think parag also talks about this in the parag-thread)
I think I will be going for CMR/CMP now.

John,
I do not know a lot about webservices in J2ee, but If you can just access the database I would not do it any other way.

thanks
J
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic