DAO component for static data
I'm concerned about scalability and performance of my application. Therefore I decided to use an ejb-application for scalability rather than servlets.
My application uses several components that return static data from the database. The data is being held for the live of the session. Which type of components should I use in order to keep resource usage low and performance high?
So I seem to have these options:
1) Entity beans
As I read on sun's pages due to performance these should be used only for transactional purposes.
I don't need transactions though the data is static and read only.
2) Stateless session beans for DAO that return valueobjects.
What about memory usage? The data is static, so every session would have an instance of the same data. Makes for 1000 sessions 1000 classes of redundant data.
What about scalability? valueobjects implemented as pure java classes are not reusable in an ejb-way. So there's no active/passivate in the objects and only the whole bunch of objects contained in a parent container (stateful session e. g.) will be passivated when the parent container is passivated.
3) stateful session beans for DAO that hold valueobjects.
This is the way sun suggests as the "Stateful Session Bean Strategy" in their ValueListHandler Pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html
So the valueobjects may be pooled and passivated when not actually needed.
What's wrong with this?
Is there much overhead in accessing the objects? I'm not really familiar with the ejb object model...
4) a systemwide singleton. Something like one global object for all user sessions.
I don't know how to implement such. Does anyone have examplecode for this?
Such a construct might be great for memory savings.
Is synchronization necessary for a read only object? If so this will slow down the performance (1000 sessions repeatedly trying synchronized get Methods on one single object).
Something like RMI might be necessary because of different memory spaces that might influence performance. But this should be the same with ejb-objects.
So if such a construct is possible without synchronization this seems to be the best choice..
So what is best used? Anything completely different?