In general,
you should be trying to stop requirements like these. It is fine for a client to specify performance/capacity related requirements but they shouldn't be specifying requirements down to the level of detail that you are describing. What it sounds like is the client is worried about performance because they got burned with current solution they developed in C. To solve their performance issues they introduced these "startup objects" (terrible name btw). 1 + 1 = 2... therefore any peformance concerns they have are solved, in their minds, by using "startup obejcts".
My recommendation would be to first fully understand what the performance and capacity requirements are, then worry about how you are going solve these problems in your system. If caching data is the appropriate solution then definitely go that route... every good ORM solution supports the concepts of a first and/or second level cache (Hibernate, JDO, Ibatis, etc.) No, I don't consider Entity Beans a good ORM solution (not in their 2.x form at least). Regardless of which way to choose, make sure you setup iterative performance tests throughout the lifecycle of the project since it sounds like this is a hot item for the client. Remember, the worse thing that can happen is you get to the finish line and realize you have lost the race.
[ April 02, 2006: Message edited by: Chris Mathews ]