Generic Persitence Layer rather than Entity Beans

Discussions

EJB design: Generic Persitence Layer rather than Entity Beans

  1. Generic Persitence Layer rather than Entity Beans (2 messages)

    Hello,

    I have a large J2EE app for which I am about to replace the Entity Beans with JDBC. I may well use DAO and support both JDBC and Entity Beans, but I have Stateless Session Facade Beans in the back of my mind and I'm not sure whether there is an advantage in wrapping my DAO objects in Stateless Session Beans.

    My thinking behind wanting to use Session Facades and DAO, rather than just DAO, was so that I could still enlist in transactions without worrying about it in my JDBC code. However I do not think the Session Facade is the answer to my problem (see pseudo code at end of message for why I don't think it helps with transactionality).

    I am looking at supporting Entity Beans and JDBC (some persistent objects will be accessed using Entity Beans, some JDBC), so my question is this - is there an a generally preferred persistence strategy that I can use to support multiple persistence methods at the same time.

    Pseudo code to illustrate the reason I think that the Session Facades will not help the transactional problem.
    --------------------------------------------------------

    SessionBean1.method1( ) {Transaction=RequiresNew}
    CustomerDAO.create(TransferObject)
    SessionBean2.method1( )

    Let’s say SessionBean2.method1( ) fails (throws a System Exception). The transaction created when SessionBean1.method1( ) started executing would be rolled back. However, we have already committed the changes to the database in CustomerDAO.create(). Wrapping CustomerDAO in a Stateless Session Bean does not help as the JDBC code in the CustomerDAO.create() code is not enlisted in a transaction.

    So what can I do? Do I need to write JTA code in the CustomerDAO.create() method and try to enlist it in any existing transaction so that, when the transaction is rolled back, the creation of the customer record done in CustomerDAO.create() will be rolled back? Is that even possible?

    Thanks in advance,
    Paul
  2. Hi,
        I am not very sure that I understand your question properly but I think that you want to run thease three methods in one transaction.

    SessionBean1.method1( ) {Transaction=RequiresNew}
    CustomerDAO.create(TransferObject)
    SessionBean2.method1( )

    What is the sequence of your method calls.If your SessionBean1.method1 is calling the DAO create method and then I think that the transaction should get rolled back.

    cheers.
  3. Hi Paul,

    FireStorm/DAO will generate a DAO tier directly from your data model that supports both JDBC and EJB (and JDO and Hibernate).

    It also offers an option to generate a Session Bean Facade onto the DAO tier.

    It also offers the choice of implicit transactions or standard J2EE transaction management.

    You can download an evaluation copy here:

    http://www.codefutures.com/products/firestorm/download/

    Thanks,

    Andy Grove
    CTO
    CodeFutures Software