Deleting from a DataBase

[Tanya Evans]

Please can someone explain to me whether a Session Bean can be used to (say) delete a record from a database (using simple JDBC code). If the answer is YES - Can someone explain therefore why I would want (OR NEED) to use an ENTITY bean to accomplish the same task ?
I was under the impression that both Session beans and Entity beans are BOTH transactional, if this is the case - what are the circumstances when you would :-
a) USE a SLSB to DELETE/UPDATE a record
b) USE an ENTITY bean to DELETE/UPDATE a record.
I'm aware that Session beans model a business process and that entity beans model the data - hence my confusion in understanding this area.

Thanks for your help.

[Ajith Kallambella]

What is your data access gateway? - If you are using entity beans to read/update data, then you should use entity beans to delete also. If you are using a session bean/DAO model, then you should use the Session bean to delete data also. This means, you must decide on the Persistence/DataAccess strategy even before you start modelling the business process.
In short, it is recommended that you use the same data access strategy for realizing the CRUDF (ie., Create, Read, Udpate, Delete and Find) functionality. The only accepted exception to this rule is the "Fastlane JDBC Reader" method that uses Sessionbean/DAO to read data by bypassing the entity bean layer.
Hope that helps

[Tanya Evans]

For read only data and lists of information that I want to present to the user - I use a SLSB with a DAOFactory object that handles creation of the relevant "DATABASE" DAO class.
Are you saying that apart from using SLSB as a facade to entity beans, that if you use a SLSB to access data via a DAO then you would still use a SLSB to perform CRUD operations ? and thus do away with an entity bean altogether ?
Whats wrong with having a SLSB that has a local interface to an ENTITY bean that performs the CRUD operations ? Or is the ENTITY bean not really required in this instance ? (i.e, just do the CRUD operations inside the SLSB)

[Ajith Kallambella]

Are you saying that apart from using SLSB as a facade to entity beans, that if you use a SLSB to access data via a DAO then you would still use a SLSB to perform CRUD operations ? and thus do away with an entity bean altogether ?

Yes, I am hinting that you could have an architecture that does not use entity beans, but uses SB with DAO. Understand that entity beans are more expensive than session beans because they are burdened with keeping their data upto-date and hence results in multiple database roundtrips under the hood.
The only thing you give up by not using entity beans is caching. Most of the app server vendors implement smart caching aimed to reduce database round trips. Other than this one feature, EB ans SB both offer transactions, distribution, location transparency, concurrency management, JNDI lookup etc. Of course, entity bean may make your life easier(
) if you used CMP/CMR for advanced object-to-relational mapping. So that may be another deciding factor - do you need an advanced persistence framework or are you willing to write one yourself? If you need one, is entity beans your answer or are you willing to consider other emerging persistence frameworks such as JDO, Hybernate, Apache OJB etc..

Whats wrong with having a SLSB that has a local interface to an ENTITY bean that performs the CRUD operations ? Or is the ENTITY bean not really required in this instance ? (i.e, just do the CRUD operations inside the SLSB)

There is nothing wrong. You first have to decide whether you want to use entity beans. If so, it is always best to model them as local beans and have only a few remote session beans that are visible to the client.

Cheers,

[Tanya Evans]

Ajith
Thanks very much. Your explanation was perfect.