Need Clarification

Discussions

EJB design: Need Clarification

  1. Need Clarification (5 messages)

    Consider a bean having a number of finder methods and a number of get and set methods.
    Consider a situation where a client (Client_1) executes a finder method which returns say 100 records. The client scrolls through all these records, so 100 bean instances would be created and assigned to the corressponding EJBObjects (I suppose).
    Now a second client (Client_2) executes some other finder method which also returns 100 records, 50 of which are common to the one fetched by Client_1.
    My question is:
    1) Would 100 bean instances be created for Client_2 also (I don't think so) or
    2) Only 50 instances for the non-common records be created, while Client_2 would be assigned the same references for the 50 common records.
    If not so, then what if Client_1 executes a set method on one of the common records. How would the EJB Container synchronize this?




    Threaded Messages (5)

  2. Need Clarification[ Go to top ]

    I have some confusion about "How many instance of a entity bean" will be created . I have not found the application server specific documentation addressing this issue ..

    The application server that depends on RDBMS for locking can create multiple instance .
  3. Need Clarification[ Go to top ]

    Typically a remote collection( enumeration previously in EJB 1.x) is returned. The collection typically consits of Primary key wrappers. When you scroll through this list, the bean instance is created. Thus for,
    1) For Client_2 only those instances that are not present are created.

    2) If the Client_1 executes a set request on any of the bean instance the value's are changed and this can be validated by checking its values in the DB. If Client_2 is parsing the remote collection then and he gets the refrence to the instance which Client_1 has modified or will modify. The instance remains the same only the values in them change. Also if Client_1 is modifiying the instance and Client_2 tries to get that instance he will be blocked till Client_1 completes his operation(This was the main reason why transacion parameters like Read commited, Read unCommited, etc where removed).
  4. What i inderstand From EJB2.0 , Proposed Final Draft , section no 16.7.2 , page no 365 , figure 72 as follows -

    TX1 Client 1 // not realistic one
    {
        lookups entity Bean ( With PK 1)
        lookups entity Bean ( With PK 1) again
    }
    Application server may create two instance of the bean ..

    TX2 Client 2
    {
        lookups entity Bean ( With PK 1)
    }

    then which instance to block ?? further blocking of the instance is not also a good option , because if client 2 wants to only read the data , then why it should be blocked ?

    EJB spec. always describe a scenario and expected result of that . It no where mandates the way to achive the result.
    So its totally app server dependent how it manages the case.
    (I have not found any documentation of app server publishing it's internal logic )

    If anybody have one please post the list .

    Ashim Chakraborty


  5. Need Clarification[ Go to top ]

    What you are talking about is optimistic and pessimistic locking approach.

    If the app server is using a pessimistic locking approach(corresponds to Serializable access in Oracle), then client is blocked if the EJB instance with the same PK is being used by some one else. So essentially there is only one EJB instance per PK in this case. All the request for EJB instance of same PK are serialized. This is way Weblogic use to work till 5.1 version.

    In optimistic locking approach, there can be multiple instances of EJB instance with same PK. All the locking is defered is to be taken care by database itself. This is the default locking in Weblogic 6.1 version or later. But you can change it in the xml descriptors.

    Hope this helps,

    Nishchit
  6. Need Clarification[ Go to top ]

    I agree with Nischit.
    Nowadays all major application server moving towards to optimistic locking approach ( preffered option ) for perfomance issue and a design pattern to maintain the version number coming into picture .