Design question

[twilight]

I've got a EJB design-related question I hope someone could help me out with... I have a table in my database that has several entries related to each user of my application. I would normally make this an entity bean, but in this case, many of the entries related to a user will be updated / modified at once - almost never one by one.

My question is: Should I make an entity bean, and have the session bean "front-end" handle this by means of EJB finder methods in the entity bean, then looping through this list and updating the entity beans one at a time? Or should I make it a stateless session bean whose business methods directly make the desired action on all the database entries at the same time?

As this is an representation of data, I somewhat feel that I should make it an entity bean. On the contrary, as it requires updates to so many entity beans at once, making it a stateless session bean could improve performance and efficiency?

Thanks a lot for any input,
\Anders

[larry054]

Efficiency is not your only consideration. Updates done by a session bean with JDBC calls will not be seen by the entity beans unless/until they are reloaded. I'm guessing that this some kind of user security data you're talking about, so it will be accesed often. I have struggled with this issue, as I am sure others have too. The question I ask myself is: When is the overhead of entity beans worth the caching benefit?

When many users are accessing the same rows and especially when there are lots of updates, entity beans are a clear win. Entity beans in this case result in far fewer writes to the disk. When large groups of rows are read and displayed without updating, session beans doing JDBC are a clear win. In between, I would lean toward entity beans for consistencty unless the performance really kills the app.

[minamoto]

It is up to the object model you made.
Your entities may be internal and transparent to users.

When we design entity beans, we ought to have a object view as well as a database view. In the model, users don't see an entity as a database record but as a persistent object part of the object library.

If the entity is just a database record wrapper that only have the state and accessor methods and doesn't provide useful methods at all, you think twice whether it is worth an entity bean or not.

If the entity is a dependent object of other entity beans and the clients don't access the object directly, you can handle it as a value object, which is a java class or java beans.

Although CMP entity beans help our work so far, I think we can't avoid jdbc programming for balanced implementation of object design and performance. So I think it is reasonable if you take the session bean option following your object design and implement reusable Data Access Objects for it.