Discussions

General J2EE: Persistence Framework Design

  1. Persistence Framework Design (2 messages)

    Hello!

    In the light of recent discussions about Entity Beans' pros and cons I came to a decision to tell you about the persistence framework I use in my latest project.

    The idea is pretty common: I have a number of Session facades and one PersistenceManager class. The idea of that class is to deal with connections and transactins, it has the following methods: startTransaction(), commitTransaction(), rollbackTransaction(), execute (HashMap parameters, DAO dao). The main method here is execute that actually delegates to execute(HashMap parameters) method of DAO class.

    Inside each DAO class I encapsulate the logic that knows how to execute query, statement or stored procedure, populate JavaBean type object with ResultSet (usually a collection of such objects) and return it back.

    From each method of Session facade I usually have several calls to PersistenceManager and aggregate a complex object that is returned back to the presentation layer. On practice, the main part of method getUsers looks like that:

    ...

    ProxyManager proxyManager=new ProxyManager();

    proxyManager.startTransaction();

    try {

    Collection beanObjects=proxyManager.execute (params,new UsersByNameDAO());

    aggregateVO.addCollection("users",beanObjects);

    Collection beanObjects=proxyManager.execute (params,new GroupsByUserDAO());

    aggregateVO.addCollection("groups",beanObjects);

    proxyManager.commitTransaction();


     } catch (ProxyException e)
     {
       proxyManager.rollbackTransaction();
     }

    ...

    etc.

    All queries and stored procedures call syntaxes are hardcoded into one big properties file.

    This (JavaBeans and Collections) objects can easily be cached using CacheManager class - you can specify the objects that are not required to be very accurate on timely basis, you can also specify cache timeouts for them. This cache will have an ultimate control when you're using shared databases.

    Hope to get your thoughts on that subject.

    Thanks,
    Alex

    Threaded Messages (2)

  2. Persistence Framework Design[ Go to top ]

    Alex,

    One of the thing I like about this is (besides it simplicity) that the queries are not embedded in the code. Nice touch :)

    A question about transactions:
    With that framework you can start a transaction in one method call, and commit/rollback several method calls later?
    I mean: Supose that the user hit a jps page that triggers the begin of a transaction. Several pages are viewer and then the user trigger a page for the commit/rollback of the transaction. Is that possible?
    (I'm struggling with JTA to do that)

    I suppose that if I need to change the database, I only have to change the property file with the queries for the new database, is that true?


    Rafael
  3. Persistence Framework Design[ Go to top ]

    One of the thing I like about this is (besides it simplicity) that the queries are not embedded in the code. Nice touch :)


    ;)

    > A question about transactions:
    With that framework you can start a transaction in one method call, and commit/rollback several method calls later?

    Actually it's not recommended to do, but it's possible. The main idea that when you execute startTransaction() the actual JDBC connection is opened. After you execute the first JDBC statement or query within opened connection (it happens when you perform an execute() call) the actual transaction is started on a database side. If you don't call commitTransaction() or rollbackTransaction() (which actually close the connection), the connection will be remain opened. If you push this opened connection in SFSF bean and in the next session retreive it and will try to execute statement on it, it will continue within the same transaction.

    You can increase your performance sufficiently if you create a pool of opened connections and prepare all the statements you want for them - you'll deal with already prepared statements and will save some time which you use for PreparedStatement statement preparations.

    The only problem here that you can't guarantee that database will like your "long transactions" and that you can easily keep on wasting resources if you'll be unable to close your connection within the next session of a client (i.e. if a client disconnects). However, new Timer features of EJB 2.1 can easily sort out this kind of problem (in case if you find a working implementation yet).

    So, consult your database documentation before you starting with "long transactions".

    >I mean: Supose that the user hit a jps page that triggers the begin of a transaction. Several pages are viewer and then the user trigger a page for the commit/rollback of the transaction. Is that possible?
    (I'm struggling with JTA to do that)

    See above. That's possible if you use the same database OPENED connection throughout your sessions.

    >I suppose that if I need to change the database, I only have to change the property file with the queries for the new database, is that true?

    Yes.

    Or/and rewrite stored procedures in the database (if all your queries and statements are stored procedures calls). If you change your database schema - you'll do the same.

    I also finishing creation of code generator that generates DAOs and JavaBean objects from the Web (or of any other type) attributes my client supplied. You can also specify the order of DAO calls in your session bean and, ultimately, the code generator will even generate session facades for you. It speeds up the development very much.

    Alex