Will Entity Beans use one or multiple Database connections?

Discussions

EJB design: Will Entity Beans use one or multiple Database connections?

  1. Hello.

    I have a session bean acting as a facade on 2 entity beans, and am using bean managed persistence with container managed transactions.

    Each of my Entity beans open a connection to the same database (and the same username/password) by means of a JNDI lookup to a DataSource object. Thus, the sequence of events is as follows:

    1) Session bean begins transaction
    2) Session bean calls Entity EJB 1
    3) ejbLoad() of Entity EJB 1 opens a database connection, and load bean
    4)Session bean calls Entity Bean EJB 2
    5) ejbLoad() of Entity Bean EJB 2 opens a database connection and loads bean
    6) Other steps.

    So my question:

    a) Despite the fact that the second Entity Bean (EJB2) has its own "open database connection" code, will EJB2 in fact use the existing connection already opened by EJB1 rather than opening a new connection and hence requiring 2pc for transacitonal integrity?

    b) Assuming in fact that EJB2 does in fact re-use the existing database connection, how exactly is this being achieved? Is this a feature of the EJB container interception, or is it a feature of the database DataSource implementation? Do all EJB conatiners work in this fashion?

    c) If I tried to do the exact same with POJO rather than with Entity Beans, would the second java object re-use the existing db connection, or open a brand new one? Is there any way I can get POJO to work in the same way that the EJBs work above?

    Thanks
  2. <quote>
    a) Despite the fact that the second Entity Bean (EJB2) has its own "open database connection" code, will EJB2 in fact use the existing connection already opened by EJB1 rather than opening a new connection and hence requiring 2pc for transacitonal integrity?
    </quote>

    It depends on the transactional attributes of your EJB methods. If your have methods with transactional attributes that force them to be in the same transaction (e.g. "Required"), then they will share the same database connection. If you have attributes that forces a new transaction (e.g. "RequiresNew"), then the EJB will get a new connection.

    <quote>
    b) Assuming in fact that EJB2 does in fact re-use the existing database connection, how exactly is this being achieved? Is this a feature of the EJB container interception, or is it a feature of the database DataSource implementation? Do all EJB conatiners work in this fashion?
    </quote>

    Transaction/Connection management is the responsibility of the EJB container. In theory, they EJB standard allows the container some flexibility on exactly how they manage things. In practice, the major servers (those that support 2PC) behave more or less the same way, because they all have to support the XA standard. You can rely on the transaction being maintained correctly, but you cannot rely on each EJB getting literally the same connection object (the server probably uses some kind of connection interceptor/adapter wrapping the real connections).

    <quote>
    c) If I tried to do the exact same with POJO rather than with Entity Beans, would the second java object re-use the existing db connection, or open a brand new one? Is there any way I can get POJO to work in the same way that the EJBs work above?
    </quote>

    The key to getting your objects to behave this way is to use JNDI and a DataSource to retrieve your connection, so that the server can manage the transaction correctly. As a result, POJOs will behave this way as well. The only difference is that POJOs cannot mark their own transaction boundaries. If you don't care about this (you always want your POJO operations to be in one transaction), then you can invoke your POJOs from an EJB method with a transaction attribute of "Required" and everything will behave correctly.

    In fact, this is a common technique for eliminating Entity beans and replacing them with POJO persistence frameworks like JDO or Hibernate.
  3. Hi
    In most of the cases when you look up a datasource from JNDI the EJB container wil give you a wrapper over a real JBBC database connection. In this way the container knows to do some tricks like :
    * returning wrappers over the same underlying db connection for request comming from the same transaction. If only one data source is involved in the transactin the container will propably optimze the 2pc into a simple 1pc.
    * when closing the wrapper the underlying db connection is not really closed, but is returned to the connection pool.
    On every database related operation you should lookup the datasource, get the connection, do you work and close the connection. In this way you return the real connection to the pool, as oposed to when you keep the connection for the
    whole life span of your entity bean/POJO.
    Best regards, Mircea
    PS