To use or not to use Entity Beans

Discussions

EJB design: To use or not to use Entity Beans

  1. To use or not to use Entity Beans (2 messages)

    Hi !

    We are currently looking into a step-by-step migration of a client-server system with ~700 windows, ~800 tables and a few hundred users. The application is NOT a webapp with browsers but a rich client, ie. Swing.

    We have studied the J2EE papers and talked to a few people about what strategy to use.
    We HAVE to do it step-by-step, application-by-application with both environents using the same Informix database concurrently.
    This have led us to BMP. Correct ?

    Now we are facing some problems with the use of Entity Beans.

    1) The database can get updated from a "non J2EE" application when we have an Entity bean representing the same data. What will happen ? Stale data ?

    2) We have a lot of logging of user activies in the database using triggers and stored procedures. How do we identify a user in the database if we use Entity Beans ?

    3) Is Session Beans with JDBC/SQL a better plan ? We could make special session beans that match what entity beans do to isolate JDBC/SQL from session beans that handle the logic.

    4) When the old application is all ported - are there any big advangages to use Entity beans ? Switch to CMP ?

    5) How will the upcoming DAO impact on this ?

    6) Performance ?

    TIA

    Jan Nilsson
  2. To use or not to use Entity Beans[ Go to top ]

    See ***** comments below. Hope that helps.

    --
    Tinou Bao
    www.tinou.com


    Hi !

    We are currently looking into a step-by-step migration of a client-server system with ~700 windows, ~800 tables and a few hundred users. The application is NOT a webapp with browsers but a rich client, ie. Swing.

    We have studied the J2EE papers and talked to a few people about what strategy to use.
    We HAVE to do it step-by-step, application-by-application with both environents using the same Informix database concurrently.
    This have led us to BMP. Correct ?
    **** not necessarily. depends on the CMP support your app **** server gives you. EJB 1.1 is limited, but some app **** servers give you better support than others. you can **** also look into O/R tools that work with EJBs.

    Now we are facing some problems with the use of Entity Beans.

    1) The database can get updated from a "non J2EE" application when we have an Entity bean representing the same data. What will happen ? Stale data ?
    **** this should not be a problem. the container should be
    **** able to keep your entity beans in sync. the way they do
    **** is by calling ejbLoad() often. this means you make a
    **** lot of hits to the db but it's unavoidable in this
    **** situation. kind of like if you were running in a
    **** cluster, the container will have to call ejbLoad()
    **** often (start of transactions) because there's no
    **** way it knows if another instance has updated the db.

    2) We have a lot of logging of user activies in the database using triggers and stored procedures. How do we identify a user in the database if we use Entity Beans ?
    ***** in the past all my entity beans have a owner, last
    ***** updated timestamp. is this what you mean?

    3) Is Session Beans with JDBC/SQL a better plan ? We could make special session beans that match what entity beans do to isolate JDBC/SQL from session beans that handle the logic.
    **** harder to say better. depends on what you are doing.
    **** entity beans are shared among clients. session beans
    **** aren't, so I don't really know how you plan on doing **** this. if you just need to do queries than yea,
    **** session beans with jdbc is better for of performacne.

    4) When the old application is all ported - are there any big advangages to use Entity beans ? Switch to CMP ?
    **** the advance of CMP is it should be easier, less error
    **** prone, better performing (overall). why code something
    **** from scratch when somebody else has already provided
    **** you the tool, provided it meets your needs.
    **** entity beans i think depends on how complex your
    **** business objects are. to me, entity beans should be
    **** business objects, with both data and business methods.
    **** but i think more often than not people use them as
    **** simple data objects. if entity beans are used as data
    **** objects i don't see much advantage and lot of overhead.
    **** otherwise they do provide you with all the services of
    **** ejbs.

    5) How will the upcoming DAO impact on this ?
    **** DAO? To me data acccess object is just a way to
    **** encapsulate db calls. do you mean JDO?

    6) Performance ?
    **** i had some issues with performance but looking back
    **** most were probably my fault :-) and probably a little
    **** refactoring and chaning of certain attributes would
    **** have increased performance a lot.


    TIA

    Jan Nilsson
  3. To use or not to use Entity Beans[ Go to top ]

    Tinou
    Thx for your answer !

    Some clearification (I hope)

    1) ejbLoad only at start of transaction ?
    The db will have to do lots of reads and the buffers of the db will change frequently wich will force the db to make physical access to the discs and not to shared memory buffers .... Better or worse for overall performance if the appserver's cach is out of sync or the db's cach is out of sync ?

    2) I understand it like this :
    The appserver starts a lot of connections to the db and later use this as a connection pool. The db see those connections as ONE user, the appserver. When a stored procedure asks the db / os who the user is the answer will be "appserver" but the actual human that do the changes are "Joe". That is, we will logg "appserver" as the person who did the changes and not "Joe" ?

    3) The structure of our apps are that the user enters some kind of id and get a set of rows that matches that id. IE start of a name gives every person whos name starts with those characters, but much more complicated and often with a join to several tables to collect the text for a code. Is this a good canditate for a session bean with JDBC ? We don't lock any rows at this time, just present them to the user who pics one and contius to work.

    5) Sorry about the DAO :-( There are SOOO many 3-char's out there. I ment JDO.

    And again - thx for the answer

    Jan