Been trying to track down an answer to the following problem, obviously unsuccessfully. The thing is, I have a set of entity beans which represents data about the configuration of the running J2EE-application. It is constantly accessed so I need to performance optimize to the max.
The data represented by these entity beans never changes during runtime, but it is "relationally" related to other data in the system. So I don't really want to store it in environment entries. In theory, however, I could have done so.
Problem is, no matter how I configure these beans they always seem to generate at least two hits at the underlying database engine: One for the primary keys, another for the bean data. Now, the ideal situation for me would simply be to have all entity bean instances loaded once and then never access the underlying database beyond that. After all, the data never changes, so there's no real need for further database hit in the first place. Is there any way to have a table loaded into memory "once and for all" like this?
Problem solved if this is possible. If not I'll probably resort to using an in-memory (non-persistent) in-process hsqldb database. Seems reasonable that this would yield optimal performance if database hits are unavoidable. However, since the database is non-persistent it should initially be empty, and I need to prepare it (create and populate tables) before use every time the datasource is deployed. Is there any way to achieve this, say by including a set of sql statements to be run at deployment time?
Third question: Using an in-memory datasource or not, is it possible to have purely in-memory entity beans? If so, any way to have these support clustering?
Would JBossCache solve any of these problems, perhaps?
