Hi There,

I had been suggested by few people to design a system in the following architecture

ControllerServlet --> SLSB[Delegator] -> BusinessBean/DAO

The transaction handling is done in the DAO and it is user transactions [setting auto commit to false]. Now what is the advantage of this solution. The SLSB is just a delegator of requests, infact it too is like a controller, it just redirects the call to the corresponding DAOs. The reason quoted was that this allows in better transaction handling.. since the txns are handled in the DAO, what has the EJB[SLSB] to do with this. Please set aside reasons like component model, remote access, with respect to data access and transactions etc., does this have any advantage over a servlet->javabean->DAO approach.

Hi!

When you execute code (including your DAO) in the EJB container, you are not allowed to manage transactions. The EJB container does this job, and will normally not allow you to do it. (I know that OC4J from Oracle throws an exception when you make Connection.commit() in the EJB container.)

Chapter 17 in the EJB 2.1 spec. is about transactions. In section 17.3.4 it is said that you are not allowed to call commit() or rollback() if you let the container manage the transactions.

If you want to make commit and rollback explicitly on you JDBC connection you have to execute the code in the servlet container and use the Servlet->JavaBean->DAO approach you propose.

/Tomas

This may not be in direct response to your question, but one thing I would recommend is that the transactions should be handled by your SLSB, and not your DAO. You can issue a rollback in your DAO (since the DAO is providing the persistence service and is responsible for maintaining the data integrity of its own data), but commits should always be issued by the use case controller (in your case the SLSB) requesting the persistence service. The reason being, the DAO could be called in many different contexts (by many different use case controllers), and it should be the caller who should make the final call on when the data/transaction should be committed, because it is the caller who started it, and knows best about the business functionality. (this is very important if you have one use case SLSB calling other use cases in order to perform a task)

Thanks
DS

I have some problem about DAO.I use dao object insert some recorde,which time the connection.commit method will be invoked in EJB container.

Am assuming you are referring to Container Manager Transactions, and if so, the container would commit the transaction at the end of the EJB method call that initially invoked the transaction. So if your SLSB calls a DAO, and the DAO inserts a record, and passes the control back to the SLSB, at the time when SLSB method ends, the container will commit the transaction. Hope thats what you are looking for.

Thanks
DS

Hi there,
I generally prefer to do Controller -> SLSB -> DAO where the transactions are handled by SLSB. I havent come across any problem so far with this type of implementation. So I would prefer to have SLSB managing Transactions and DAOs doing Data Access....
GUYS... If you know any issues on using this strategy in implementation please do let me know...
Thanks and Regards
Raj

I am using CMT in SLSB, from where I invoke a dao which inserts into two tables. The insert into the second table fails due to invalid data, but the transaction is not rolled back, there is a new record in the first table, which should not have been there in case of a successfull rollback. I have tried using setRollbackOnly(), but this too does'nt work. It is the same case if you use bean managed transactions too, the transaction is getting rollback even after calling the rollback() statement.

Any suggestions..

Mohamed Zafer

My company builds simple web applications.

We have: a controller servlet, "service" objects, business (value) objects, and DAO's

If you want to learn more abut transaction demarcation and DAO's, please read my article:

http://www-106.ibm.com/developerworks/java/library/j-dao/