Transactions - strange effect on performance

Discussions

EJB programming & troubleshooting: Transactions - strange effect on performance

  1. Transactions - strange effect on performance (4 messages)

    I have been running some performance analysis tests on an EJB 2.0 application running on Borland Enterprise Server v 5.2.1.

    When tweaking the Container Transaction attributes for the EJBs so that a methods transaction attribute is changed from "required" to "supports" or "not supported" they appear to have an adverse effect on response time.

    This dosnt make sense to me? Is there something I am missing?

    Its not a major problem, but am curios to know why this is the case.

    Any ideas would be appreciated.

    Regards,

    John Miller
  2. Using transactions is a major factor in the EJB server's ability to cache data in the middle of operations. Therefore, an EJB operation that involves multiple EJB interactions often runs better if it is fully transactional.

    Here is a (simple) example:

    Suppose you have a session bean that reads data from an Entity bean with 10 CMP fields, and stores that data in Data Transfer Object to be sent to the client. If the operation is transactional, the data in the Entity bean can be cached in memory at the beginning of the transaction. This is because the underlying record in the database is lock by the transaction and will not change.

    However, if the operation is not transactional, the EJB server may be forced to make more calls to the database. In between retrieving field 1 and field 2, the values in the database may change, so the entity must make an extra query to the database. Ditto for between field 2 and 3, field 3 and 4, etc.

    Note that the above example may not apply to every situation and every EJB server, because each server uses different caching strategies, but it gives you an idea of why transactional operations might perform better than non-transactional operations.
  3. Thanks for the reply. I can see how that would effect performance.

    However, the method in question is on a Stateless session bean which is acting as a Session Facade to a Business Object Layer. Its not using any other EJBs and simply delegates down to the BO layer.

    Any more ideas would be great.
  4. I don't know much about Borlands server, but I suspect it is the same sort of issue. Maybe the server is using some kind of caching strategy for the JDBC calls in your business objects. Or maybe it has to do with the way the EJB server manages its connection pools. Or maybe the server is just buggy.

    If you really want to know exactly what is going on, I would suggest you take the question to one of Borland's support forums.
  5. Thanks. Will do that.