3

I have an application that has a struts 1.1 and EJB 2 combination, but now we are introducing a new piece into it with hibernate 3.2. The hibernate DAO's run in parallel with the EJB 2 session bean DAO's with pure JDBC. I am concerned about the jdbc connections management in this case. Since EJB 2.0 has container managed connections and transactions. But in the case of hibernate we begin and commit a hibernate transaction, Will it be safe to assume there will not be any issues with this architecture.

Need some analysis help.

PM

I was contemplating on the same issue, if hibernate module which might access existing tables being used by JDBC DAO's whose transaction is managed by Session Beans. But here is my approach:

  1. I will have a delegate that invokes the EJB session bean, and since this bean will be responsible to manage transactions, I will create my hibernate DAO's and invoke them from this session bean, which I assume will not have any issues.

  2. The hibernate session factory for this application will be instantiated once using the hibernate plugin that will be part of the struts config xml and will be saved as part of the servlet context and then the action class will pass this sessionfactory instance from the EJB session bean delegate to the hibernate DAO.

  3. I guess this will be a clean approach, since the transaction will be managed by the EJB Session bean which are deployed onto the websphere. The JDBC connection pools management since is configured on the websphere and being accessed using the datasources, hibernate does not have to worry about this.

Please help me if I am on the right path with my assumptions ?

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
Gopal
  • 71
  • 1
  • 9

3 Answers3

0

Transactions demarcate logical unit of work and hence are inherently isolated. But I am wondering why you need a combination of both. If you are already using EJB2 + JDBC why not stick to this?

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
0

Hibernate can be used without any problem with CMT (or BMT) session beans, share a connection pool with JDBC code and participate in the same transaction.

See the whole section 11.2. Database transaction demarcation and in particular 11.2.2. Using JTA.

What is not clear is if the Hibernate module will be "isolated" from the entities managed via JDBC. If you'll access the same tables via both APIs, you'll have to take some precautions:

  • don't expect to mix JDBC entities in a graph of Hibernate entities (the inverse is possible though).
  • respect and mimic Hibernate optimistic concurrency strategy when updating rows via JDBC
  • bypassing Hibernate's API won't trigger any cache update (if you're using the 2nd level cache) in which case you'd have to trigger it yourself.
Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
0

Here is one of the possible solutions

A common JNDI Datasource, which will be used both in EJB's and Hibernate.

Ratna Dinakar
  • 1,573
  • 13
  • 16