Skip to Content
author's profile photo Former Member
Former Member

Does SAP J2EE Engine violate EJB Specification?

Hi All,

i'm porting a quite complex application from JBoss to SAP Web Application Server. This application uses BMP Entity Beans. Now I was at a point where all was running, but there where strange effects of inconsistent system states. Through logging I found out that my entity beans are not locked by the container, when they are accessed concurrently by different threads of the container. That caused dirty reads on the database. I could verify this with a document here at the SDN: Programming EJBs. In this document SAP says that SAP J2EE Engine uses commit option C and that locking mechanisms are up to the bean provider (me). When I read the EJB Specification there is explicitly stated that the bean provider does not have to worry about locking and concurrent access regardless of the commit option used by the container (See EJB Specification 2.0 FR 12.1.11).

So is it true that SAP violates the EJB Spec and does make BMP Entity Beans impossible to use?

Any answers welcome!!

Greets Chris

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Jan 07, 2005 at 09:40 AM

    Hello Christian,

    I am sorry for the late reply, I hope it is not too late for you.

    My statement is that SAP fulfils the EJB spec and both BMP and CMP entity beans are usable. Here is the explanation:

    1. According to the EJB Specification 2.0 FR 12.1.11 (quoted by you), the EJB Container provides a certain strategy for achieving proper synchronization. The strategy provided by the SAP EJB Container is the first one, i.e. “activate multiple instances of the entity bean, one for each transaction in which the entity object is being accessed“ The data is read from the database at the beginning of each transaction and written back at the end of the transaction.

    2. You are right – “the Bean Provider does not have to worry about concurrent access from multiple transactions”. However, this is true to a certain degree. The EJB Container ensures Read Committed isolation level, i.e. prevents from dirty writes and dirty reads. If one wants to achieve higher isolation (e.g. Repeatable Read isolation level), then CMP entity beans must be used or the BMP entity beans must be enhanced with additional locking.

    3. Going back to the problem you faced – please check the isolation level of the data source that your application uses (it should be at least Read Committed), the behavior of the database and the database driver you use. As dirty reads cannot be caused by the EJB Container, they can appear only if the database allows them.

    Best regards,


    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.