1) Is 3.0 compliant with our version of WLS?
2) Does version 3.0 require XA Drivers?
3) If we have a distributed (clustered) environment and start a transaction which spans EJB's participating in the transaction which are running on separate boxes, and each of those EJB's creates a session, will the transaction and database access work appropriately (especially in the case of a failure and subsequent rollback)?
3a) Should each EJB create a session or should the coordinator of all the EJB calls pass session information to each of the EJBs and therefore the coordnator would be incharge of the rollback?
3b) What happens with the transactioning in the above when JMS is thrown into the mix.
4) If you are just using searching functionality...for instance one of our applications allows consumers to query for doctors in their area and this may produce multiple results. And the user may have to search multiple times to get the exact requirements that they are looking for. Is this a good place for Hibernate and do I base that decision on how the object model is used in this portion of the application, or do I say no to Hibernate because I am specifically looking for speed searches without updates/deletions/insertions?

Thanks for your time & help,

jay

I did not receive any responses on these questions. I am really interested in getting a response at least for question 3.

Help.

-jay

I can just say that hibernate if configured properly will join any running JTA if its available.

Just so that I understand this right for explaining later.

If I have multiple servers that are running a J2EE container and EJBs, let's say that an action from the web makes a request to an SLSB or java class that works as a coordinator for multiple calls to other EJBs that may live on different containers. If I managed the transaction in the SLSB/java class through JTA...any Hibernate Sessions would just attach themselves to that open transaction. So if one of the calls from that SLSB to another EJB caused a RuntimeException within a Session...that RuntimeException would propagate to the transaction that it is apart of and therefore the transaction from the originating SLSB/java object would rollback all Session activities that occurred within that transaction. The same being with CMT. While a Session object attaches itself to a JTA transaction, it is the JTA transaction that makes the true commit to the database/rollback and not the opening/closing of the separate Session objects that are living in each of the EJBs?

Thanks,

-jay

The scenario I suggested is actually portrayed in this article:

http://www.onjava.com/lpt/a/852



So as I explained in the previous post, it does not appear that Hibernate should add any additional complexity to this situation. The fact that the JMS call or the EJB B call may open a Session do some updates/inserts/deletions and then close the Session should be seen as the same way a JDBC Connection would be opened, queries ran, and then closed.

So it seems to me that Hibernate does not put any additional requirements onto the scenario of having a single transaction span multiple databases and app servers, any different than JDBC/JTA would require. Is this correct?

Thanks,

-jay

Yes, as explained in the first paragraph of the Transaction documentation: http://www.hibernate.org/hib_docs/v3/re ... tions.html