Multiple Entity Creation Optimization

Discussions

EJB design: Multiple Entity Creation Optimization

  1. Multiple Entity Creation Optimization (2 messages)

    Here is a scenario in my application,

    There is an entity bean say "A". There is a single operation in our application which creates about 150-200 instances of entity A (creates 150-200 tuples in a database table). So when invoking that particular operation, memory shoots up.

    I am using ejbCreate() to create the entity. Please note every instance of A is a shared component and requires consistent access during somepoint of time during the application. I dont want all the entities to be in method ready state immediately after the creation. However the ejbCreate() automatically make the entities method ready.

    Now, is it a better design to create the tuple in the table using a session bean with simple JDBC calls [instead of ejbCreate()], and use findByPrimaryKey() when there need to be a shared access. Or is there any better design addressing this scenario.

    Thanks,
    Shreedhar
  2. You might want to consider what you do in the case of reading multiple rows. For example, say you have a Customer Entity Bean, and you need to get a list of customers from the database. Are you going to bring an Entity Bean to the method ready state for each customer? Probably not. I would think you are using a ResultSet or RowSet to build up a list of small objects that identify the customers so the client/user can select one. The solution for the bulk writes should be analagous to the solution you use for the multiple reads. I think you are on the right track going directly to JDBC. Hopefully this little analogy gives you some justification.
  3. My 2 cents[ Go to top ]

    Shreedhar,

    You can also you batch processing for multiple and fast inserts. Latest Weblogic supports this option for CMP. It also supports programmatic cache invalidation when needed - this is what you need to use with shared databases.

    Stored procedures can be a good idea if you stick with JDBC.

    Alex