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.
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.