Are Entity beans memory objects?

[Vivek Mehra]

I am new to EJB and i have a problem with EJB utilized in my project.I have a requirement in my project that as soon as our system i.e our project system starts i need to have certain objects in memory which hold values from database tables and remain in memory till the system is stopped.

My question is are entity beans(CMP or BMP) the answer to this requirement? because from what i see is that after entity beans are looked up and a transaction is done they are removed from memory(not immediately but after passivation it seems according to LRU algorithm by container).The problem is that they don't become memory objects as i don't want them to be removed from memory.

I am confused about this .I hope someone can guide me on this.Thanks in advance.

[Rajesh Pandey Rajesh Pandey]

Hello Freind

You are thinking good.You can use either CMP or BMP both have done same task but difference is that in case of CMP you have work on limit which is available in CMP but in case of BMP you have not any limitation you can manage all means transaction as you want.Second thing is that you have said about memory object and Least Recently Uses Algorithm i want to say you just reverse algo Just in time which is uses for information regarding state activation and passivation means container called those object which is just called before.i think my answer can help your.

With Best Regards
Rajesh Pandey
email :-- [e-mail]
India Delhi

[Chris Mathews]

I am new to EJB and i have a problem with EJB utilized in my project.I have a requirement in my project that as soon as our system i.e our project system starts i need to have certain objects in memory which hold values from database tables and remain in memory till the system is stopped.

That is very odd requirement. That is about as low-level as you can get from an implementation aspect... definitely not something I would expect to see in a requirements document. Can you explain the purpose of this requirement to maybe give us a better idea of what you are being asked to accomplish?

[Vivek Mehra]

Thanks Rajesh and Chris.

Actually the main purpose is to avoid hits to the the database.The current system was developed in C and has memory objects and the system has been in place for a long time now.The feeling they have is that something like "startup objects" which have all values needed for validations could be loaded in memory since the amount of transactions per second is huge.The need to go to the database would slow down the process.

Rajesh,sorry but i didn't quite understand by what you meant by "reverse algo" :

Second thing is that you have said about memory object and Least Recently Uses Algorithm i want to say you just reverse algo Just in time which is uses for information regarding state activation and passivation means container called those object which is just called before.

[Chris Mathews]

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 ]

[Babji Reddy]

Volume, frequency of the data that you are trying to pre-load matters when deciding the type of cache.
I too agree that EJB 2.x is not a reasonable caching solution.
However, if you are trying to avoid frequent db access for few KB of data (like some flag, properties checks), you could load the data using simple JDBC into a singleton and serve it for the complete JVM.
If the data really spans multiple tables, whose structure might change over time and requires maintenance in future, then you can think of externalizing these mappings thro ORM caches.